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Preface 


This National Aeronautics and Space Administration (NASA) Contractor Report summarizes and 
documents the work performed to develop system standards for the proposed C-band (5091- to 
5150-MHz 1 ) airport surface communications system. 

The report consists of two volumes: 

• Volume 1 is devoted to the Concepts of Use, Initial System Requirements, and Architecture and 
includes AeroMACS Design Considerations. 

• Volume 11 describes AeroMACS Prototype Evaluation and presents Final AeroMACS 
Recommendations. 

This work was completed under the NASA Aerospace Communication Systems Technical Support 
(ACSTS) contract, based on direction provided by the Federal Aviation Administration project-level 
agreement (PFA FY09_GlM.02-02vl) for “New ATM Requirements — Future Communications” as a 
follow-on to the FAA/EUROCONTROF (European Organisation for the Safety of Air Navigation) 
Cooperative Research Agreement (Action Plan 17 (AP-17)), commonly referred to as the Future 
Communications Study. 


'With a possible future extension into the 5000- to 5030-MHz band, pending a decision at the World 
Radiocommunications Conference in 2012. 


iii 
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Executive Summary 


ES.l Introduction 

This report is being provided as part of the NASA Glenn Research Center Aerospace Communication 
Systems Technical Support (ACSTS) Contract (NNC05CA85C), Task 7: “New ATM Requirements — 
Future Communications, C-Band and L-Band Communications Standard Development.” 

Task 7 is separated into two distinct subtasks — each aligned with specific work elements and 
deliverable items identified in the Federal Aviation Administration’s (FAA) project-level agreement 
(PLA) and with the FAA fiscal years 2009 and 2010 New ATM Requirements — Future Communications 
Project and spending plan for these subtasks. 

The purposes of subtask 7-1, and the subjects of this report, are the definitions of the concepts of use 
(ConUse), high-level system requirements, and architecture; the performance of supporting system 
analyses; the development of test and demonstration plans; and the establishment of operational capability 
in support of C-band aeronautical data communications standards to be advanced in both international 
(International Civil Aviation Organization, ICAO) and national (RTCA) forums. 

The future C-band (5091 to 5150 MFIz 1 ) airport surface communication system is referred to as the 
Aeronautical Mobile Airport Communications System (AeroMACS). 

Assumptions and constraints for this report follow: 

• The 5091- to 5150-MFIz spectrum allocation for AeroMACS use at the World 
Radiocommunications Conference (WRC-2007) is provisioned only for use on the airport 
surface. This allocation is within the aeronautical mobile (route) service (AM(R)S) band. 
Therefore, AeroMACS applications are constrained to mobile applications on the airport surface. 
This is interpreted to include communications for non-mobile (i.e., fixed) applications 
provisioned within a mobile AeroMACS network that supports the safety and regularity of flight. 

• The proposed AeroMACS is assumed to provide an increase in overall air-to-ground (A/G) 
communications systems capacity by utilizing the new spectrum (i.e., in addition to existing very 
high frequency, VHF spectrum). 

• The scope of this ConUse and requirements report includes airport surface A/G communications 
and ground-to-ground (G/G) communications. 

• AeroMACS will be designed specifically for data communication. Voice communication may be 
provided as a digital data communications service (e.g., voice over internet protocol (VoIP)). 

• This report assumes that the data communications system developed as part of the FAA Data 
Communications Program (Data Comm) will precede an A/G AeroMACS implementation and 
deployment. 

• Although some critical services could be supported, AeroMACS networks will also target non- 
critical services, such as weather advisory and aeronautical information services implemented as 
part of an airborne access to System Wide Information Management (SWIM) program. 

• AeroMACS is to be designed and implemented in a manner that will not disrupt other existing 
services operating in the C-band. Additional interference research and testing will determine if 
any operational constraints are to be imposed, such as limiting the number of users, the time of 
the day, the duration, and so on. 

The work is being performed in two phases. This report builds on Phase 1 results as presented in the 
Phase 1 report (Ref. 1). This Phase 11 document is separated into two volumes. Volume 1 is devoted to the 
concepts of use, system requirements, and architecture and provides some additional detail for the 
concepts developed during Phase 1. New studies conducted during Phase 11, including airport 
categorization and channelization methodology, expand the AeroMACS design considerations section. 
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The second volume addresses the AeroMACS prototype architecture and performance evaluation and 
presents final AeroMACS recommendations resulting from the tests. 

ES.2 ConUse 

A process recommended in the “National Airspace System: System Engineering Manual” (SEM, 

Ref. 2) was adopted as a guide in developing ConUse and requirements for the proposed system. 

Figure ES-1 summarizes the steps. 
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Figure ES-1. — ConUse development process. Acronyms are defined in Appendix A. 

ES.2.1 Identify Operational Needs for a New System 

Operational needs for a new system are supported by describing the current system and its associated 
problems and capability shortfalls. “System Requirements Document, Next Generation Air/Ground 
Communications (NEXCOM)” provides a good description of the FAA’s current analog A/G voice 
communications system used for ATC (Ref. 3). 

The Next Generation Air Transportation System (NextGen) concept of operations (ConOps) 
summarizes the current attributes (and associated constraints) of the voice-based A/G communications 
system as follows (Ref. 4): 

• Limited data communications for air traffic management (ATM) and operational control 

• Limited access to real-time weather and aeronautical data 

• Voice communications routine for ATM 

• Analog voice 

• Analog weather information display systems 

• A/G and G/G communications 

• Loss of communications due to beyond line-of-sight (BLOS) aircraft position (e.g., over the 
ocean) 

• Individual ground systems for each information type brought to the flight deck 

• Point-to-point aircraft communications based on ATC sectors 

There are several principal shortcomings of the current A/G voice communications system, including 
lack of automation, limited or no data communications availability, aging infrastructure, technology 
limitations, and spectrum saturation. The resulting operational problems, if not addressed, could lead to 
service degradation and limit the introduction of new or expanded services. These, in turn, could 
potentially compromise safety of operation and increase operating costs. Saturation of spectrum is the 
problem specifically mitigated by the introduction of a new C-band system (AeroMACS); the other 
operational problems would also be mitigated with AeroMACS. 

Current G/G communications on the airport surface are conducted predominantly over a combination 
of wire and optical fiber cabling and a limited number of point-to-point line-of-site radio li nk s. 

The limitations imposed by the current G/G communications infrastructure could result in restrictions 
in the deployment of new ATM services, resulting in the following service limitations (Ref. 4). 
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• Limited ATM (e.g., traffic) information on the flight deck 

Limited data shared among stakeholders for collaborative decision making (CDM) processes 

• Information sharing in support of operational security performed manually instead of 
electronically 

• Not all stakeholders able to access data they need 

• Stakeholders unable to use custom data sources 

ES.2.2 Provide Proposed System Justification 

Rather than being a National Airspace System (NAS) service itself, G/G and A/G communications 
are enablers of NAS services. It is important to note that the FAA’s “Final Program Requirements for 
Data Communications” (Ref. 5) recognizes that “the scope of the mission shortfalls identified herein [is] 
broader than will be addressed solely by a data communications capability.” Because of the limitations 
and constraints of implementing data communications using very high frequency digital link (VDL) 

Mode 2 over a congested aeronautical VHF band, the FAA’s Data Comm Program will focus principally 
on implementing the most critical air traffic services (ATS). This will provide opportunities for 
AeroMACS networks to augment data communications on the airport surface by enabling 
communications of less critical and essential ATSs to address the shortfalls listed. Even though each of 
the shortfalls listed above is meant to be addressed to some extent by Data Comm using VDL Mode 2, 
there are opportunities to overcome these shortfalls to an even greater extent during the later program 
segments of Data Comm (e.g., late Segment 2 and Segment 3) using link technologies such as 
AeroMACS with greater bandwidth capabilities. This would augment the benefits already attained 
through the earlier VDL Mode 2 Data Comm segment implementations (i.e., Segments 1 and 2) by 
providing a broader scope of services. 

ES.2.3 Define Proposed System and ConUse 

Some FAA objectives defined in the FAA’s NextGen portfolio are based on the requirement to 
support future air traffic growth. AeroMACS will be designed and developed to help meet those 
objectives in part by expanding the data communications capacity in the airport surface domain. Global 
harmonization is being ensured by developing the proposed AeroMACS component of the FRS as a 
collaborative effort of the U.S. and European partners. 

As recommended by the Future Communications Study (FCS) technology assessment, the proposed 
airport surface communications system (i.e., AeroMACS) is based on the Institute of Electrical and 
Electronics Engineering (IEEE) 802.16 standard and its extension, IEEE 802.16e-2005 (Ref. 6), and will 
be implemented in the aeronautical C-band (5091 to 5150 MHz). A new standards profile for airport 
applications is currently being developed within an RTCA special committee (SC-223) to operate in the 
C-band and make use of the scaling properties inherent in the IEEE 802. 16e standard. An updated version 
of the standard, IEEE 802.16-2009, provides the basis of ongoing profile selection. 

The proposed AeroMACS could provide supplemental means to the ATC communications required 
by the operating rules (e.g., VHF voice communications) in continental airspace (albeit on the airport 
surface) and will adhere to the data link characteristics noted in the “Safety and Performance 
Requirements Standard for Air Traffic Data Link Services in Continental Airspace (Continental SPR 
Standard)” (Ref. 7). 

Figure ES-2 and Table ES-1 show the potential AeroMACS services in three categories: air traffic, 
airline, and airport. 
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Figure ES-2. — Potential AeroMACS Service Categories in United States (Ref. 8). 


TABLE ES-1.— AEROMACS SERVICE EXAMPLES AND PROVISION OPTIONS (REF. 8) 


Air Traffic Services 

Service Examples 

• Air traffic control commands beyond Data Comm Segment 3 

• Surface communications, navigation, and surveillance (CNS) fixed assets 

Provision Options 

• Government-owned (licensed)/Govemment-operated (GO/GO) 

• Government-owned (licensed)/Commercially-operated (GO/CO) 

• Non-competed service extension via FAA Telecommunications Infrastructure (FTI) 

• Open commercial competition by FAA 

Airline Services 

Service Examples 

• (AOC) 

• Airline Administrative Communications (AAC) 

• Advisory information 

• System Wide Information Management (SWIM) 

• Aeronautical Information Management (AIM) 

• Meteorological (MET) data services 

Provision Options 

• Commercially-owned (licensed)/Commercially-operated (CO/CO) 

• Non-competed service extension via exiting AOC service providers 

• Airline service provision internally 

• Open commercial competition by airlines 

Airport Operator/Port Authority Services 

Service Examples 

• Security video 

• Routine and emergency operations 

• De-icing/snow removal 

Provision Options 

• Local Government-owned (licensed)/Commercially-operated (GO/CO) 

• Commercially-owned (licensed)/Commercially-operated (CO/CO) 

• Open commercial competition by Operator/Port Authority 


This report focuses on the ATS and advisory data services that are defined in the communications 
operating concept and requirements (COCR) and are not expected to be provided by the FAA Data Comm 
Program through Segment 2 (Refs. 8 and 9). The following list shows candidate COCR services 
potentially enabled by AeroMACS: 
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• Flight information services 

o Data link operational terminal information service (D-OT1S) 
o Data link runway visual range (D-RVR) 
o Data link surface information and guidance (D-S1G) 
o Data link significant meteorological information (D-S1GMET) 

• Flight position, flight intent, and flight preferences services 
o Pilot preferences downlink (PPD) 

o Flight plan consistency (FL1PCY) 
o Wake service (WAKE) 

• Emergency information service 

o Urgent contact (URCO) — if in conjunction with other more routine services 

Additional data services that may be provided via AeroMACS may be identified as NextGen and Single 
European Sky ATM Research (SESAR) progress. In addition, AeroMACS could provide the means for A/G 
data transfer on the airport surface to support the FAA’s Aircraft Access to SWIM (AAtS) program. 

Table ES-2 lists the operational scenarios and concepts envisioned for the midterm NextGen airport 
surface flight phase. Although most, if not all, of these concepts are currently envisioned for Data Comm, 
they are technology independent and, thus, equally valid for an AeroMACS implementation. 


TABLE ES-2.— NEXT GENERATION AIR TRANSPORTATION SYSTEM (NextGen) 
MIDTERM OPERATIONAL CONCEPTS FOR THE AIRPORT SURFACE PHASE 


Phase of flight 

NextGen midterm communications operational concept (from Ref. 10) 

Flight planning 

Access to flight planning infonnation will be available to authorized users via a secure network 
and will include a publish/subscribe capability so that users can receive automatic updates when 
conditions change along the proposed flight path. 

Push back, taxi, and 
departure 

As the time for the flight approaches, the final flight path agreement will be delivered as a data 
message to pilots who access the agreement before beginning the flight. 


Table ES-3 illustrates the potential operational use of the proposed AeroMACS based on the COCR 
services previously identified as potential applications (Ref. 9). 

TABLE ES-3.— USE OF THE PROPOSED AEROMACS IN THE AIRPORT FLIGHT DOMAIN 


[Acronyms are defined in Appendix A.] 


Operational services 

Airport domain phases 


Predeparture airport 

Departure taxi airport 

Arrival airport 

Anival taxi 


domain 

domain 

domain 

airport domain 

Flight infonnation services 

D-OTIS a 

D-OTIS a 

D-OTIS a 

D-RVR a 


D-RVR a 

D-RVR a 

D-RVR a 

D-SIG 


D-SIG 

D-SIG 

D-SIG 



D-SIGMET 

D-SIGMET 



Flight position, flight intent, and 

PPD 

PPD 

PPD 

PPD 

flight preferences services 

FLIPCY 

FLIPCY 

FLIPCY 

FLIPCY 


WAKE 

WAKE 

WAKE 

WAKE 

Emergency information service 





Services suitable for Airborne 

Aviation Digital Data Service (ADDS), AWOS Data Acquisition Service (ADAS), 

SWIM (generally weather 

Expanded Tenninal and Tower Data Service, General Information Message Distribution 

advisory and aeronautical 

Service, Information Display System (IDS) Data Service, NextGen Network Enabled 

infonnation services) 

Weather (NNEW) service, 13 NOTAM distribution service, TMA Flight Data Service, 


WARP/WINS NEXRAD service 




“At the time of this report D-OTIS and D-RVR are listed as part of the RTCA SC-214 scope (Ref. 8). As noted throughout 
this report, the services are considered candidates for AeroMACS if not implemented by the Data Comm program. 
b It is possible that the infonnation provided through the NNEW service could range from advisories for routine forecasts 
though safety-critical transmission of certain hazardous weather warning messages, which might limit the extent to which 
this service could be provided over commercial links. This requires further investigation. 
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Table ES-4 lists the airline operational control (AOC) data services noted in the COCR v.2.0 
(Ref. 10). Position Report (POSRPT) is not included in the table because it is not provided on airport 
surface. Some of the services listed, for example Software Loading (SWLOAD), would be provided the 
ground, while others may be applicable to wheels on and off the ground scenarios with AeroMACS 
enabling these service on the airport surface only. 

The AOC services in Table ES-4 may be mapped to the Flight Regularity category (Ref. 9) and may 
be transported over the AM(R)S link. Services with larger bandwidth requirements, for example 
WXGRAPFI, UPL1B, SWLOAD, may be more suitable to provide via AeroMACS while services 
involving smaller traffic volumes may be more appropriate for a VDL-2 system. 


TABLE ES-4.— COCR V.2.0 AOC DATA SERVICES 


Service 

Acronym 

AOC Data Link Logon 

AOCDLL 

Cabin Log Book Transfer 

CABINLOG 

Engine Performance Reports 

ENGINE 

Flight Log Transfer 

FLTLOG 

Flight Plan Data 

FLTPLAN 

Flight Status 

FLTSTAT 

Free Text 

FREETXT 

Fuel Status 

FUEL 

Gate and Connecting Flight Status 

GATES 

Load Sheet Request/Transfer 

LOADSHT 

Maintenance Problem Resolution 

MAINTPR 

Real Time Maintenance Information 

MAINTRT 

Notice to Airmen 

NOTAM 

Out-Off-On-In 

OOOI 

Software Loading 

SWLOAD 

Technical Log Book Update 

TECHLOG 

Update Electronic Library 

UPLIB 

Graphical Weather Information 

WXGRAPH 

Real-time Weather Reports for Met Office 

WXRT 

Textual Weather Reports 

WXTEXT 


The New AOC/AAC Services document provided by SANDRA (Ref. 12) specifies additional 
services not mentioned by the COCR, but recommended based on industry feedback and the 
standardization activities. This document is a work in progress. 

The RTCA SC-223 has formed a User Services and Applications Survey (USAS) Working Group 
(WG) to collect information from various AeroMACS stakeholders. The group compiled the data for the 
existing and future applications in the following functional domains: 

• Air Traffic Control/ Air Traffic Management (ATC/ATM) 

• Aeronautical Information (AIM) 

• Airlines/Cargo Operations (Airline/Cargo Ops) 

• Aiiport Operation (Airp Ops) 

• Aiiport Infrastructure (Airp Infr) 

SESAR Project P 15.2.7 input was incorporated noting the new AOC services proposed by SANDRA 
(Ref.il). 

At the time of this report, the list of applications compiled by the USAS WG was not validated for 
AM(R)S use or duplication with the FAA Data Comm program. Rather it attempts to present a superset of 
communication services that can potentially be enabled by AeroMACS. 
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Appendix E presents USAS WG’s projection of the most likely applications to be supported by 
AeroMACS. The version presented in Appendix E is a work in progress document with the estimated 
completion time December 31, 2010. 

ES.3 AeroMACS Network Requirements 

A middle-out approach was adopted to identify the high-level requirements applicable to AeroMACS. 
In this approach, the top-down functional requirements were derived from the ConUse and the associated 
functional capabilities. In parallel with that process, a bottom-up assessment of existing requirements in 
relevant documents such as the NAS SR-1000 (Ref. 13), the COCR (Ref. 12), and Data Comm 
performance requirements and their applicability to the current needs for AeroMACS was performed. 

AeroMACS could provide a communication link to transfer surveillance and weather information, 2 
facilitate flight and resource management, enhance CDM, and enable the exchange of aeronautical 
information in the future NAS. The tables in Appendix B document the select RTCA NAS ConOps 
(Ref. 14) found applicable to the proposed AeroMACS. 3 

The desired AeroMACS functional capabilities have been derived from the identified NAS ConOps 
presented in Appendix B and mapped to (1) high-level aeronautical A/G and G/G communication 
functions and (2) specific COCR ATS services. Table ES-5 lists the AeroMACS high-level functional 
capabilities and presents this mapping . This encompasses a top-down approach to the development of 
functional requirements. 


TABLE ES-5.— MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE 
SYSTEM (NAS) CONCEPTS OF OPERATION (ConOps) 

[Acronyms are defined in Appendix A.] 


Desired AeroMACS 
capabilities 

NAS ConOps references (Ref. 14) 

Functional 
hierarchy reference 

C ommunications 
operating concept and 
requirements (COCR) 
air traffic services 
(ATS) 

Enable air-to-ground 
(AG) and ground-to- 
ground (G/G) 
communications for 
fixed-to-mobile as well as 
fixed-to-fixed services. 

S-l; S-3; S-4; 

W-2; W-3; W-8; W-9; W-10; W-12; W-13; 
W-14; W-15; 

FM-1; FM-6; FM-8; FM-12; FM-14; FM-15; 
FM 17; FM-23; 

A-2; A-6; A-12; A-15 

C. 1.1. 1.2 
C.l. 1.2.2 
C.l. 1.4.1 

D-OTIS a 

D-RVR a 

D-SIG 

D-SIGMET 

FLIPCY 

WAKE 

PPD 

Support addressed 
communication for 
delivery of information to 
individual and multiple 
users 

S-l; 

W-10; 

FM-6; FM-8 

C.l. 1.1.2 
C.l. 1.2.2 
C.l. 1.4.1 

D-OTIS a 

D-RVR 11 

D-SIG 

D-SIGMET 

FLIPCY 

PPD 

Support broadcast 
communication for 
delivery of information to 
multiple users 

S-l; S-4; 

W-2; W-3; W-12; W-14; 
FM-8; 

A-12 

C.l. 1.1.2 
C.l. 1.2.2 
C.l. 1.4.1 

D-OTIS a 

D-RVR a 

D-SIG 

D-SIGMET 

WAKE 


2 In today’s environment both, surveillance and weather information would be uplinked to the aircraft on the ground. 
In the future, a downlink may be applicable to transfer this data to the controller. 

Although the RTCA document describes the NAS evolution in terms of three time periods — near (up to 2005), mid 
(2005 through 2010), and far (beyond 2010) — most concepts identified in the document are found applicable for the 
proposed AeroMACS, which will necessarily be implemented beyond 2010. 
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TABLE ES-5.— MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE 
SYSTEM (NAS) CONCEPTS OF OPERATION (ConOps) 

[Acronyms are defined in Appendix A.] 


Desired AeroMACS 
capabilities 

NAS ConOps references (Ref. 14) 

Functional 
hierarchy reference 

C ommunications 
operating concept and 
requirements (COCR) 
air traffic services 
(ATS) 

Support delivery of real- 
time information in a 
timely manner 

S-l; S-3; 

W-16; 

FM-1; FM-2; FM-9; FM-10; FM-12; FM-15; 
FM-18; FM-25; FM-26; 

RM-3; RM-7; 

A-4; A-7; A-ll 


D-RVR a 

D-SIG 

D-SIGMET 

FLIPCY 

WAKE 

PPD 

Enable demand, periodic, 
and event communication 

S-l; 

W-12 


All services 

Accommodate a wide 
range of data types (e.g., 
surveillance reports, 
weather raw data and 
products, flight profiles, 
etc.) to support common 
situational awareness 

S-3; 

W-2; W-3; 
A- 1 ; A- 5 


All services 

Support multiple quality- 
of-service (QoS) 
provisions 



All services 

Support authentication of 
users and controlled 
access to NAS 
information (security) 

W-l 


All services 

Provide support of both 
Federal Aviation 
Administration (FAA) 
and non-FAA ground 
users 

S-l; 

FM-12; FM-14; FM-20; 
A-ll 


All services 

Avoid single points of 
failure 

RM-6 


All services 

Provide a scalable 
solution 



All services 

Provide standards-based 
solution 



All services 


a At the time of this report D-OTIS and D-RVR are listed as part of the RTCA SC-214 scope. As noted throughout this report, 
the services are considered candidates for AeroMACS if not implemented by the Data Comm program. 
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High-level AeroMACS functional requirements were then constructed from the functional 
capabilities as shown in Table ES-6. 


TABLE ES-6.— AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS 


System Junctions 

AeroMACS high-level functional requirements 

Enable air-to-ground (A/G) and ground-to-ground 
(G/G) communications for fixed-to-mobile as well 
as fixed-to-fixed services. 

The system shall enable ground-to-air (G/A) communication for fixed-to- 
mobile users. 

The system shall enable G/A communication for mobile-to-mobile users. 
The system shall enable A/G communication for fixed-to-mobile users. 
The system shall enable A/G communication for mobile-to-mobile users. 
The system shall enable G/G communication for fixed-to-fixed users. 

Support addressed communication for delivery of 
information to individual and multiple users. 

The system shall support addressed communications to individual users. 
The system shall support addressed communications to multiple users. 

Support broadcast communication for delivery of 
information to multiple users. 

The system shall support broadcast communication to multiple users. 

Support delivery of real-time information in a 
timely manner. 

The system shall support delivery of real-time information in a timely 
manner. 

Enable demand, periodic, and event 
communication. 

The system shall enable demand communication. 
The system shall enable periodic communication. 
The system shall enable event communication. 

Accommodate a wide range of data types (e.g., 
surveillance reports, weather raw data and products, 
flight profiles, etc.) to support common situational 
awareness. 

The system shall accommodate a wide range of data types (e.g., 
surveillance reports, weather raw data and products, flight profiles, etc.) to 
support common situational awareness. 

Support multiple QoS provisions. 

This functional capability points toward performance requirements. 

Support authentication of users and controlled 
access to National Airspace System (NAS) 
information (security). 

The system shall support authentication of users (security). 

The system shall support controlled access to NAS information (security). 

Provide support of both Federal Aviation 
Administration (FAA) and non-FAA ground users. 2 

The system shall support FAA ground users. 

The system shall support non-FAA ground users. 

Avoid single points of failure. 

The system shall avoid single points of failure. 

Provide a scalable solution. 

The system shall provide a scalable solution. 

Provide a standards-based solution. 

The system shall provide standards-based solution. 


a To support increasing collaboration among NAS users, the proposed system shall accommodate a wide range of NAS users by 
accepting NAS data from NAS data sources, both internal and external to the FAA. Users may include aircraft, airline operation 
centers, service providers, FAA users, and other Government agencies. 


Although the top-down approach employs the classic “clean-sheet” system engineering process, the 
bottom-up approach addresses how the AeroMACS fits into the existing environment. 

Functions identified in the NAS SR- 1 000 document — plan flights, monitor flights, control traffic, 
support flight operations, monitor NAS operations, and plan NAS usage — cut across all the AeroMACS 
capabilities shown in Table ES-6. 

The functional requirements applicable for an AeroMACS operating on the airport surface (shown in 
Table 7) were extracted from the NAS requirements specified in the NAS SR- 1000. Unless specifically 
stated otherwise, these could apply to A/G or G/G communications, for fixed-to-mobile or fixed-to-fixed 
applications. 


xiii 
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TABLE ES-7.— NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS 


| NAS functions 

Communication requirements 3 

Plan flights 

Evaluate flight 
conditions 

The NAS shall disseminate the status of special use airspace to users. (08760) 

The NAS shall disseminate weather information to users to support flight planning. 
(27150) 

The NAS shall disseminate aeronautical infonnation to users to support flight planning. 
(27160) 

Manage flight plans 

The NAS shall disseminate flight infonnation to users. (00010) 

The NAS shall disseminate flight plan infonnation to users via external data 
interfaces.(00410) 

The NAS shall disseminate flight plan infonnation to users via air-ground data 
communications. (00970) 

The NAS shall disseminate flight data summaries to users. (00070) 

The NAS shall disseminate flight plans to users. (02160) 

The NAS shall disseminate flight plan clearances to users. (02900) 

Monitor 

flights 

Collect aircraft 
navigation information 
(collect dependent 
surveillance 
infonnation) 

The NAS shall retrieve actual flight infonnation. (10000) 

The NAS shall acquire actual flight infonnation from aircraft outside of independent 
surveillance coverage. (03320) 

Monitor aircraft status 

The NAS shall respond to emergency transmission received via radio communications. 
(12600) 

The NAS shall respond to emergency transmissions received via data link. (12620) 

The NAS shall disseminate essential infonnation on missing aircraft. (13130) 

Report (disseminate) 
aircraft status 

The NAS shall display position information, to specialists, for aircraft that were detected 
independent of aircraft equipage in qualifying aerodromes. (24530) 

The NAS shall transmit conflict-free flight path recommendations to expedite resolution 
of emergency situations. (12820) 

The NAS shall disseminate aircraft flight information for each controlled aircraft to 
specialists. (02720) 

The NAS shall disseminate the current location for each participating aircraft to ATCSCC 
[air traffic control system command center] Specialists. (10940) 

The NAS shall disseminate the current location for each participating aircraft to Traffic 
Management Coordinators. (10980) 

Control 

traffic 

Address active aircraft 
conflicts 

The NAS shall disseminate recommended collision avoidance maneuvers to users. 
(03690) 

Control aircraft 

The NAS shall disseminate aeronautical infonnation to users via air-ground data 
communications. (07440) 

Coordinate traffic 
control distribution 

Hie NAS shall acquire pilot reports (PIREP). (05530) 

The NAS shall disseminate weather advisories via direct specialist to pilot 
communications. (09290) 
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TABLE ES-7.— NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS 


j NAS functions 

Communication requirements 3 

Support flight 
operations 

Manage weather 
infonnation 

The NAS shall maintain communication links adequate to avoid user delay in gaining 
access. (07090) 

The NAS shall disseminate weather information to users continuously. (07110) 

The NAS shall disseminate current weather effect along the users proposed flight 
path. (07470) 

The NAS shall disseminate forecast weather in effect along the users proposed flight path. 
(07480) 

The NAS shall disseminate intensity levels of weather by route of flight to users. (08260) 
The NAS shall disseminate intensity levels of weather by geographic area to users. 
(08300) 

The NAS shall disseminate weather advisories to users in response to a request. (09300) 
The NAS shall broadcast the latest approved aerodrome conditions on communications 
media accessible by aircraft on the ground. (09340) 

The NAS shall broadcast the latest approved terminal area conditions on communications 
media accessible by aircraft on the ground. (09360) 

The NAS shall respond to user requests for weather information from NAS facilities 
through common carrier communications networks. (09370) 

The NAS shall disseminate selected weather information directly to appropriately 
equipped aircraft. (09420) 

The NAS shall provide flexible and convenient access to required weather information to 
users. (19380) 

Operate navigation 
aids b 

The NAS shall disseminate navigational accuracy correction values for supplemental 
navigation systems to users. (17040) 

The NAS shall disseminate correction values for navigational aids to users. (16790) 
The NAS shall disseminate available supplemental terminal navigation guidance 
information error correction values to users. (14820) 
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TABLE ES-8.— NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS 


NAS functions 

Communication requirements 11 

Monitor NAS 
operations 

Monitor NAS flight 
operations 

The NAS shall disseminate future delay advisories in effect along the users proposed 
flight path. (07500) 

The NAS shall disseminate traffic advisories upon user request. (09120) 

The NAS shall provide traffic advisories to aircraft on the surface. (30270) 

Maintain NAS 
infrastructure 

The NAS shall disseminate airway usage information to users. (00030) 

The NAS shall disseminate route usage information to users. (00050) 

The NAS shall disseminate aeronautical infonnation to users via external data interfaces. 
(07430) 

The NAS shall disseminate aeronautical infonnation per user request. (07130) 

The NAS shall disseminate aeronautical infonnation upon user request continuously. 
(07340) 

The NAS shall disseminate aeronautical data for a maximum of 8 specified locations per 
request. (07400) 

The NAS shall disseminate the status of supplemental navigation systems to users. 
(17010) 

The NAS shall disseminate status of supplemental navigation systems to users. (16770) 
The NAS shall disseminate flow control information to users via external data interfaces. 
(07920) 

The NAS shall disseminate derived restrictions to the user. (11700) 

The NAS shall disseminate alternate courses of action relative to flight restrictions to 
users. (1 1790) 

The NAS shall disseminate terrain infonnation compliant with terrain, ground and 
obstacle infonnation accuracy requirements, to users upon request. (03900) 

The NAS shall disseminate manmade obstacle infonnation compliant with terrain, ground 
and obstacle information accuracy requirements, to users upon request. (03940) 

The NAS shall disseminate ground infonnation compliant with terrain, ground and 
obstacle infonnation accuracy requirements, to users upon request. (25520) 

The NAS shall disseminate filtered terrain infonnation to users. (25560) 

The NAS shall disseminate filtered ground infonnation to users. (25570) 

The NAS shall disseminate filtered manmade obstacle infonnation to users. (25580) 

Plan NAS 
usage 

Plan traffic flow 

The NAS shall disseminate preferred route information at least 24 hours prior to it 
becoming effective. (07280) 

The NAS shall disseminate military air traffic control plans related to national 
emergencies. (16140) 

The NAS shall disseminate flow control information to users via external data interfaces. 
(07920) 

The NAS shall disseminate interfacility traffic flow plans. (1 1970) 

The NAS shall disseminate derived restrictions to the user. (1 1700) 

The NAS shall disseminate derived alternative courses of action to the user. (1 1720) 

The NAS shall determine flight restrictions for specific aircraft. (11760) 

The NAS shall disseminate flight restrictions to users. (1 1770) 

The NAS shall disseminate alternate courses of action relative to flight restrictions to 
users. (1 1790) 

Assess traffic flow 
performance 

The NAS shall disseminate reports on equipment performance. (18870) 
The NAS shall disseminate reports on maintenance activities. (18880) 

The NAS shall disseminate reports on equipment repair activities. (18890) 


■“Numbers in the table correspond to communication requirements in the NAS SR-1000 (Ref. 13). 

b These services are typically provided via satellite communication (SATCOM) but could be provided via a ground-based system. 
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Performance requirements were derived to define system capabilities based on the developed 
functional requirements and considering the propagation characteristic of the C-band. This report 
summarizes the NAS performance requirements found to be relevant to the proposed AeroMACS as 
documented in the NAS SR- 1000 (Ref. 13). Note that these are high-level NAS requirements that do not 
specify how they should be implemented. 

Typically high-level requirements are technology independent. Perhaps unique to the development of 
the AeroMACS requirements is the identification a priori, by virtue of the extensive FCS technology 
assessment and ICAO endorsement, of the recommended technology by which AeroMACS will be 
implemented, that is, IEEE 802. 16e and the updated standard, IEEE 802.16-2009 (Ref. 15). This allows 
the identification and development of quite specific requirements depending on the desired application or 
service to be provided. The report provides a preliminary approach for identifying and developing 
AeroMACS requirements in the context of the IEEE 802. 16e and 802.16-2009 broadband 
communications standards, and their characteristics. 

Although actual parameters will depend on the architecture of the communication network, the size of 
the network, and the provisions for redundant communication support, typical performance parameters for 
the physical and link layer requirements for individual communication services are presented in 
Table ES-9. 


TABLE ES-9.— COMMUNICATION SERVICE REQUIREMENTS 
[Acronyms are defined in Appendix A.] 


Communication 

service 

Example airport 
application 

Quality of service 
(QoS) class 

Performance 

parameters 

Typical 

values 3 

Supported 
by IEEE 
802.16-2009 

Low to medium 
speed point-to-point 
data link 

Backup for sensor cable 
link (i.e., weather 
sensor) 

nrtPS 

Data rate 
PER 
Delay 
Jitter 

100 kbps 
l.OxlO -3 
1 sec 
1 00 psec 

Yes 

High-speed point- 
to-point data link 

Backbone-linking base 
station (BS); link to 
relay gateway node in 
remote area 

UGS 

Data rate 
PER 
Delay 
Jitter 

1 Mbps 
l.OxlO -3 
1 00 msec 
100 nsec 

Yes 

Point-to-multipoint 
broadcast data 

Scheduled broadcast of 
weather info, NOT AM 

nrtPS 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -3 
1 sec 
<1 psec 

Yes 

Point-to-point 
command and 
control data 

Remote operation of 
ADS-B ground station 

rtPS 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -6 
100 msec 
<1 psec 

Yes 

Command and 

control 

network 

Operation of surface 
devices at remote airport 

Best effort 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -4 
200 msec 
<10 psec 

Yes 

Digital voice 
network 

Provide N circuits for 
ATC or AOC operations 

UPS; 

ERT-VR service 

Data rate 
PER 
Delay 
Jitter 

10 kbps x N 
l.OxlO -3 
100 msec 
<100 psec 

Yes 

Point-to-point video 
link 

Airport surveillance; 
robotic vehicle 

UGS 

Data rate 
PER 
Delay 
Jitter 

600 kbps 
l.OxlO -3 
200 msec 
<10 psec 

Yes 


NASA/CR — 201 1-216997/VOL1 xvii 




TABLE ES-9.— COMMUNICATION SERVICE REQUIREMENTS 
[Acronyms are defined in Appendix A.] 


Communication 

service 

Example airport 
application 

Quality of service 
(QoS) class 

Perfonnance 

parameters 

Typical 

values 2 

Supported 
by IEEE 
802.16-2009 

Basic mobile 

Handoff control for 
voice; low-speed data 
sessions 

UGS 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -3 
200 msec 
<10 psec 

Yes 

Multimedia 

CDM 

rtPS 

Data rate 
PER 
Delay 
Jitter 

1 Mbps 
l.OxlO -3 
1 00 msec 
<10 psec 

Yes 


a End-to-end delay, one direction. 


ES.4 Architectural Description 

The initial AeroMACS network architecture is based on the IEEE 802.16e-2005 communications 
standard that was recently incoiporated into the IEEE 802.16-2009 standard (Ref. 14). The primary mode 
for operation of an IEEE 802.16-2009-based system is a point-to-multipoint architecture. The standard is 
Internet Protocol (IP) based and provides secure connectivity between users and services. Figure ES-3 
depicts is a notional depiction of a wireless point-to-point system in an airport context that illustrates 
several applications that could potentially be supported by an AeroMACS network. Detailed descriptions 
of the end-to-end network architectures are provided in later sections of this report. 

AeroMACS is envisioned to provide communications for both mobile and fixed infrastructure. An 
AeroMACS network can support fixed infrastructure in areas of scarce communications, providing wide 
bandwidth wireless links in place of cables that can be expensive and disruptive to install. Once an 
AeroMACS network is installed at an airport, a communications link can be instantiated by simply 
placing an AeroMACS radio at the remote data site interfaced through Ethernet ports, and by 
programming the network to authenticate and authorize service for the remote data terminal. AeroMACS 
provides the flexibility to quickly implement new links to remote sites for primary, backup, and 
emergency communications. The benefit that AeroMACS provides for mobile application 
communications is unequaled in terms of flexibility and traffic bandwidth. 
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Potential AeroMACS Applications 


Airlines & Airport/Port Authority 
FAA Air Traffic Control/Management 


Airport 

Surveillance 

Radar 


Multilateration 

Surveillance 


Navigation 

Aides 


Security 


Gate Operations 


FAA Managed 
AAA Server 


Service Vehicles 


FAA Base 
Station & Core 
Server 


FAA and Airline 
Communications 


Remote 

Transmitter/ 

Receiver 


Weather 

Radar 


Figure ES-3. — Airport point-to-multipoint communications service. Acronyms are defined in Appendix A. 


The system architecture framework can be applied at all airport locations. Deploying an AeroMACS 
architecture solution at a particular airport requires several tradeoffs to obtain the best performance, 
including the 

• Location and number of base stations (BSs) 

• Number of base transceiver station (BTS) antenna sectors to employ per BS 

• Type of backhaul system to connect the BSs and support the access service network (ASN) 

• Number of subscriber station (SS) terminals that can be serviced by a BS 

A design process, including a site survey, coverage model, spectrum analysis, and capacity analysis, 
provides a formal method of adapting the standard architecture to each airport. Capabilities of existing 
airport communication systems should be surveyed and factored into the need for new capacity. 
Components will vary by airport because of differences in size, layout, and applications. 
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Table ES-10 lists the parameters that must be included in design considerations for an AeroMACS 
network. 


TABLE ES-10.— AeroMACS NETWORK DESIGN CONSIDERATIONS 


Design 

category 

Parameters 

Considerations and system design parameters 

Base station 

Mounting placement 

Total network data throughput 

(BS) 


Line-of-sight/non-line-of-sight (LOS/NLOS) coverage area 
Low-level blockage avoidance 


Number of BS and base 

BS throughput 


transceiver station (BTS) sectors 

Channel bandwidth and available spectrum 


Multiple input, multiple output 

BS cell-radius requirements 


(MIMO) order 

Transmitter (Tx) power 

Near-line-of-site and blocked-path performance 
Multipath mitigation 
Mobility dropouts 

Interference to out-of-band users will be decreased by MIMO because total 
radiated power can be reduced. 


Antenna polarization 

Cross-polarized versus spatially separated antennas 


Maximum cell range 

Number and placement of BSs 

BTS sector and subscriber station (SS) Tx power 


Controlled-pattem antennas 

Use beam steering and beam-shape adaptation to increase throughput and 
avoid interference. 


Frequency band 

5091- to 5150-MHz aeronautical mobile (route) service (AM(R)S) band 
approved during the 2007 World Administrative Radio Conference (WARC 
2007). 

Addition of 5000- to 5030-MHz band is under consideration. 


Spectrum co-user interference 

BTS sector antenna patterns control direction of radiation. 


(i.e., Globalstar satellite) 

Use minimum BTS sector and SS Tx power to achieve required data 
throughput over coverage area. 

ss 

Mounting height 

Avoid low-level structural and temporary blockages. 


MIMO order 

Tx power 

Near-line-of-site and blocked-path performance 
Multipath mitigation 
Mobility dropout avoidance 


Antenna polarization 

Cross-polarized versus spatially separated antennas 


Maximum cell range 

Tx power 

Near-line-of-site and blocked-path performance 
Multipath mitigation 
Mobility dropouts 


Frequency band 

Controlled and set by BTS sector connection 
SS must have matching frequency capability. 


Spectrum co-user interference 

BTS sector antenna patterns control the direction of radiation. 


(i.e., Globalstar satellite) 

Use minimum BTS sector and SS Tx power to achieve required data 
throughputs over coverage area. 
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TABLE ES-10.— AeroMACS NETWORK DESIGN CONSIDERATIONS 


Design 

category 

Parameters 

Considerations and system design parameters 

Channel 

Throughput rate 

Highest throughput application sets the minimum channel bandwidth. 

bandwidth 

Mobility performance 

A wider bandwidth enables better channel equalization and better tracking of 
multipath variations during mobility. 


Multipath performance 

Better equalization of short-path multipath with wider channel bandwidths 


Efficient use of spectrum 

Number of channels that fit within the 59-MHz allocated AM(R)S spectrum. 
Refer to Section 6.2.2 for a detailed discussion about center frequency 
selection. 


Co-channel interference 

There are fewer options for nonoverlapping frequency reuse in a large 
number of cells with wide channel bandwidths. 


Hardware limitations 

20-MHz channel bandwidth requires fast digital processing and may not be 
implemented by a particular hardware supplier. 5 MHz and 10 MHz are 
currently supported by the industry. 

Modulation 

Adaptive or fixed 

Fixed modulation requires the use of lowest order modulation and lowest data 
throughput; higher order modulation will cause dropouts during mobility. 


Modulation rates 

Use of all specified options maximizes data throughput for fixed and mobile 
SSs. 


Forward error correction (FEC) 
coding rate 

Use of all specified options maximizes data throughput for fixed and mobile 
SSs. 

BTS power 
class 

Fade margin 

Fade margin allowance is set during network design to establish link 
reliability. 


Co-channel interference 

Minimize Tx power to stay below the detection threshold of another BTS 
sector in a frequency reuse layout. 


Spectrum co-user interference 
(i.e., Globalstar satellite feeder 
uplinks) 

Minimize Tx power to reduce interference to co-users of the spectrum. 


Range 

Tx power affects the signal-to-noise ratio and modulation rate at the outer 
edge of cell coverage. 


LOS and NLOS operation 

Fade margin allowance increases for NLOS operation. 


Mobile operation 

Fade margin allowance increases for NLOS operation. 


Power amplifier power-output 
limitations 

Orthogonal-frequency-division multiplexing (OFDM) modulation has a high 
peak-to-average ratio, making high Tx power expensive. 

SS power 
class 

Fade margin 

Fade margin allowance is set during network design to maintain link 
reliability. 


Co-channel interference 

Minimize Tx power to stay below the detection threshold of another BTS 
sector in a frequency reuse layout. 


Spectrum co-user interference 
(i.e., Globalstar satellite uplinks) 

Minimize Tx power to reduce interference to co-users of the spectrum. 


Range 

Tx power affects signal-to-noise ratio and modulation rate from the outer 
edge of cell coverage. 


LOS and NLOS operation 

Fade margin allowance increases for NLOS operation. 


Mobile operation 

Fade margin allowance increases for mobile operation. 


Power amplifier power-output 
limitations 

OFDM modulation has a high peak-to-average ratio, making high power 
expensive. 
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TABLE ES-10.— AeroMACS NETWORK DESIGN CONSIDERATIONS 


Design 

category 

Parameters 

Considerations and system design parameters 

Media 
Access 
Control 
(MAC) layer 
and physical 
layer 

Maximum mobile speed 

120 km/hr is a value derived from other specified parameters and provides 
guidance about achievable maximum speed. 

The COCR requirement is 160 kt (296 km/hr) 

IEEE 802.16-2009 specification does not directly support COCR 160-kt 
requirement. A cost/benefit analysis is needed to assess the benefits of 
achieving this speed. 

50 kt is established as the maximum mobile speed for the following reasons: 

1 . 40 kt was established during RTCA SC-223 discussions as the 
maximum taxi speed thought to occur at a commercial airport 

2. An operating margin of 10 kt was requested by EUROCAE 

Repeater operation 
(IEEE 802. 16j) 

IEEE 802. 1 6j is an amendment to IEEE 802. 16e standard that is incorporated 
in the IEEE 802.16-2009 standard. 

BS repeater functionality may provide fill-in coverage in shadow areas with 
minimal added radiation and interference. 

Use of this feature will be dependent on commercial WiMAX industry 
implementation of the repeater functionality in hardware. 

Transmitter/receiver 
time-division duplex 
(TDD)/frequency-division 
duplex (FDD) mode 

C-band AM(R)S spectrum allocation width does not support cost-effective 
FDD operation. 

Quality of 
service 
(QoS) 

Time delay 

Services such as voice, and command and control applications will require 
guarantees on maximum time delay allowed. 

Time jitter 

Services that are sensitive to jitter are to be identified. The use of frame 
buffering should be considered for each sensitive application. 

Message priority 

Safety and reliability requirements will help specify message priorities. 

Scheduling 

The scheduling algorithm will take message priority into account along with 
QoS requirements. 

Message integrity 

Security and message integrity guarantees will depend on the type of QoS 
service flow selected. 
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ES.5 Inputs to Network Design 


ES.5.1 Identify Operational Needs for a New System 

An essential element in designing and deploying an AeroMACS network is a comprehensive RF 
design. An accurate design will ensure that the deployed wireless network provides the necessary 
coverage, capacity, and reliability, with minimal interference, that satisfies the service requirements. 
Although it is possible to gauge the performance of radio links through theoretical means, real-life 
deployments must take into account variables from the environment to achieve optimal performance and 
minimize coverage holes and RF cochannel interference. Figure FSM- illustrates a top-level design flow 
for new AeroMACS network. 

Before the design process can begin for an airport, general guidelines should be defined. Guidance on 
airport categorization, channelization methodology and power limitation recommendations are essential 
inputs to an AeroMACS network design. These guidelines are discussed in this report. 


Define AeroMACS 
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• Data backhaul 
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• Site ownership 
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Figure ES-4. — AeroMACS network design process. 


ES.5.2 Airport Categorization 

The purpose of this airport categorization task is twofold. First, creating a set of airport categories 
based on common airport characteristics and design objectives would facilitate initial AeroMACS 
architecture designs and enable budgetary projections. Though each AeroMACS network will be 
implemented with its own unique characteristics, including the number of sites and channels required to 
provide adequate service, initial system designs and budgetary estimates often rely on typical parameters. 

Second, the results are not intended to drive the final system design, but rather to offer high-level 
guidance to the potential AeroMACS technology and policy development sponsors and service providers. 
These may include the FAA Spectrum Office, various FAA Program Offices, airlines, airports, and 
others. 

In addition to coverage and capacity considerations, a business plan and cost of the proposed system 
will play an integral role in defining airport categories. 

General Aviation is the largest type of airport in the U.S. system. This statistic demonstrates that 
categories should not be limited to the commercial service hubs, as this would exclude a significant 
number of airports that could potentially implement AeroMACS. 
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Smaller airports may be interested in attracting new customers by offering additional services. A 
business plan will address if these services could be enabled by AeroMACS and offer sustainable 
financial benefits to an airport. 

Airports with less FAA presence and infrastructure may have different goals and resources than large 
hubs with extensive FAA presence. Although FAA interest in an AeroMACS may be limited, 
opportunities for other sponsorships could open up. 

The level of existing communication services at an airport needs to be taken into account. A business 
plan will take under consideration whether the puipose of AeroMACS is to augment existing services or 
provide a green field solution. 

Airport categorization used by the FAA was found most pertinent to this task because it relates to 
both aspects of categorization — traffic type and volume — and geographical size. 

Table ES-1 1 provides a summary of the proposed airport categories for AeroMACS resulting from 
this study. 


TABLE ES-1 1.— PROPOSED AEROMACS AIRPORT CATEGORIES 


FAA airport 
category 

Potential AeroMACS users 3 

Potential 

AeroMACS 

architecture 

Comments and guidelines 

Large Hub 

(LH) 

Primary 

FAA, airports, airlines, other 
service providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks, 
food service and baggage carts 

More than 2 
sectored BSs 

Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air-to- ground 
communication as well as for the use of service 
vehicles on airport surface. 

LHs concentrate on airline passenger and freight 
operations and offer limited general aviation use. 

LHs have the greatest delays of all Commercial 
Service (CS) airports which may lead to aircraft 
spending more time in the airport, potentially 
increasing capacity requirements to support air to 
ground communication in this domain. 

Medium 
Hub (MH) 
Primary 

FAA, airports, airlines, other 
service providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks, 
food service and baggage carts 

2 b sectored BSs 

Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air-to-ground 
communication as well as for the use of service 
vehicles on airport surface. 

Unlike LHs, MHs support a substantial amount of 
general aviation traffic in addition to carrier aviation. 
A business plan would target both categories, together 
or separately. 

Small Hub 
Primary 

FAA, airports, airlines, other 
service providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks, 
food service and baggage carts 

1 to 2 b BSs 

Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air to ground 
communication as well as for the use of service 
vehicles on airport surface. 

Less than 25 percent of runway capacity is used by 
airline operations supporting many general aviation 
activities, making AeroMACS less attractive to 
airlines. Business plan may need to target AeroMACS 
for general aviation use. 

Non-hub 

Primary 

FAA, airports, other service 
providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks 

1 to 2 b BSs 

Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air to ground 
communication as well as for the use of service 
vehicles on airport surface. 

Heavily used by general aviation with enplaning less 
than 0.05 percent of all commercial passenger 
enplanements 
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TABLE ES-11.— PROPOSED AEROMACS AIRPORT CATEGORIES 


FAA airport 
category 

Potential AeroMACS users 2 

Potential 

AeroMACS 

architecture 

Comments and guidelines 

Non- 
primary CS 

Airports, FAA, other service 
providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks 

l b BS 

Number of 
channels per BS 
depending on 

Used mainly by general aviation potentially making 
AeroMACS less relevant to the FAA. 

Relievers 

Airports, FAA, other service 
providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks 

l b BS 

Number of 
channels per BS 
depending on 

Specialized airports providing pilots with attractive 
alternatives to using congested hubs. Have a 
significant number of based aircraft. 

AeroMACS may enable services to attract more users 
to a particular airport. 

General 

Aviation 

Airports, other service 
providers 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks 

l b BS 

Number of 
channels per BS 
depending on 

Often located in rural areas. 

With limited existing communication infrastructure at 
some airports, AeroMACS may offer a green-field 
solution. 

AeroMACS may enable services to attract more users 
to a particular airport. 

Low 
Activity 
Landing 
Areas (Non- 
NPIAS) 

AeroMACS business case might not be supportable 


“Further granularity can be achieved, if desired, by collecting and or obtaining statistics from the FAA or the airlines for 
different airport surface vehicles to quantify the potential users. 

b More BSs may be required to provide indoor coverage. The use of one BS may be acceptable when AeroMACS is used as 
one path in a redundant communications system. 

Guidelines presented in this section are based on system engineering judgment and the results of the 
tests performed within the NASA Glenn AeroMACS prototype implemented in the communications, 
navigation, and surveillance (CNS) test bed located on Glenn Research Center property and adjacent 
Cleveland Hopkins International Airport (CLE) property, also known as the NASA-CLE CNS Test Bed. 
The fidelity of these recommendations will increase as new data becomes available, both policy and 
technical, related to practical implementations of AeroMACS. 

Results of the work being performed by RTCA SC-223 to better define services to be supported by 
AeroMACS may affect many of the categorization considerations presented here. 

Additional research, for example, traffic analysis being conducted by Continental Airlines to estimate 
voice over Internet protocol (VoIP) requirements and potential data rate needs based on current traffic 
volume (in Erlangs), may be useful in estimating the design parameters per category, such as the number 
of channels per BS. 

ES.5.3 Channelization Methodology 

Channelization is the process of segmenting the available AM(R)S allocated spectrum of 5091- to 
5150-MHz, with possible addition allocations within the 5000- to 5030-MHz band, to allow multiple 
independent applications or services to operate simultaneously on the airport surface. Channelization will 
provide for channel bandwidths of 5 MHz and possibly 10 MHz, as allowed by the AeroMACS profile. 
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A channelization plan ensures that a large set of requirements are met with services potentially 
supplied by multiple service providers. A common global channelization methodology is needed to assure 
seamless interoperability with ground-based and air-to-ground services. 

A channelization methodology is constrained by the potential for multiple categories of service and 
multiple service providers. Three distinct categories of service exist: air traffic control, airline operations, 
and airport operations. 

While a channelization methodology plan can be defined to a certain degree by analysis of technical 
factors, the final plan will be determined by FAA policy decisions regarding segregation of service traffic 
and service provider business plans. The discussion in Section 6.2.2. 2.1 addresses the FAA policy of 
segregating the transport of air traffic operations traffic. 

The purpose of this study is to establish a methodology for determining a channelization plan for 
AeroMACS in the AM(R)S band through an assessment of pertinent factors. Analysis follows the study 
map of Figure ES-5 and addresses each engineering study (ES). 



5 MHz 10 MHz 

Channel Plan Channel Plan 


Figure ES-5. — Channelization trade study map. 
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Conclusions and recommendations from individual studies within this task are summarized in 
Table ES-12. 


TABLE ES-12.— CHANNELIZATION STUDY RESULTS SUMMARY 


Study task 

Study 

number 

Constraints 

Conclusions and 
recommendations 

Network segmentation 
for ATC traffic isolation 

ES1.1 

- Two isolated networks per airport may be 
required by policy 

- Dual networks make 10-MHz channel bandwidth 
impractical for multiple sectorized BSs 

- Dual networks reduces number of airports within 
co-user interference limits 

This is a policy-driven decision 
within the constraints stated 

Efficient use of 
spectrum 

ESI. 2 

- Band-edge guard bands are needed to limit out- 
of-band emissions 

- 10 MHz channel bandwidth causes wasted 
spectrum at AM(R)S band edges beyond that 
needed for band-edge guard bands 

5 -MHz channels provide greater 
spectrum efficiency 

Multiple Access and 
Service Providers 

ESI. 3 

- Number of Access Service Providers is limited 
by spectrum allocation 

Implement single access provider 
with an option for multiple service 
providers 

Effect on initial 
acquisition time 

ES2.1 

- SS/MS units search for BS center frequencies 
during initial network acquisition 

- Significant acquisition delays are multiplied by 
the number of search frequencies required 

- Search algorithm will vary by hardware 
manufacturer and can be customized 

- BS channel center frequency options must be 
standardized for global interoperability of SS/MS 

Choose wide frequency spacing 
for BS channel center frequencies 
options. A grid based on 5-MHz 
increments specified in 
WirelessHUMAN standard is 
preferred for lowest acquisition 
time. 

In-band frequency guard 
band 

ES2.2 

- Adjacent channel interference was found to have 
insignificant effect on link performance when 
evaluated in the NASA-Glenn test bed. 

- Use reduces efficient use of spectrum 

In-band frequency guard band 
allocations are not required 

Band-edge guard band 

ES3.1, 

ES4.1 

- Spectral mask chosen for AeroMACS requires 
band-edge guard bands to prevent excessive out of 
band emissions 

- 5- MHz channel width requires a 2. 5 -MHz guard- 
band allocation 

- 10-MHz channel width requires a 3 -MHz guard 
band allocation 

Band-edge guard band allocations 
are required 

Co-user interference 

ES3.2, 

ES4.2 

- Co-user interference is minimized with efficient 
use of AM(R)S spectrum 

- Interference is increased when dual isolated 
networks per airport are required 

Use single shared-services 
network with 5-MHz channel 
bandwidth 


ES.5.4 Power Limitation Recommendations 

Multiple BS sectors, each called a BTS, will typically be required for wide-area coverage across the 
airport surface of medium and large airports. A number of factors will be used to determine the 
transmitted power of each BTS, but two overriding factors will “bracket” the allowable power range. 
First, the transmit power must provide adequate received signal strength information (RSS1) and carrier- 
to-interference and noise (C1NR) signal levels at the SS receiver to support the intended coverage area. 
The need to support a coverage area sets the lower bound for transmit power. 

The second factor that brackets transmit power, this time on the high side, is the potential to interfere 
with co-users of the AM(R)S band. Of immediate interest is interference from AeroMACS in to the 
Mobile-Satellite Service (MSS) feeder uplinks that currently exist in the AM(R)S band. Practical limits 
on AeroMACS transmissions must be implemented so that the threshold of interference into MSS is not 
exceeded. 
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A comparison has been completed between the operating parameters used in the NASA-Glenn 
AeroMACS Prototype for runway drive tests compared to the conditions used in a MITRE study of co- 
user interference. Conditions for level of interference to co-users were similar to within 0.4 dB although 
many parameters differ such as channel bandwidth, antenna mode, and transmitter power output. A 
runway drive test that maintained at least 3 Mbps throughput rate to a range of 1.7 km provides an initial 
assessment supporting excellent performance while operating within interference constraints. Additional 
checks in the future under more severe propagation conditions are required in order to gain confidence 
that viable links can be supported. 

ES.5.5 Upper Networking Layers Analysis 

The proposed AeroMACS broadband wireless specification, based on the WiMAX Forum 
specification for broadband wireless, is meant to deliver increased capacity in support of the varied 
CONOPS requirements for the National Airspace System (NAS). The desired capabilities include a 
scalable, standards-based system that avoids single points of failure and supports mutual authentication of 
users and information access (Ref. 16). A key component in ensuring the reliability and resiliency of 
communications networks is a comprehensive approach to securing the end-to-end network. 

Communications in an AeroMACS network is connection oriented. As a result, connections must be 
authenticated, authorized and established prior to any data transmissions. Further, the AeroMACS 
network elements must be authenticated and authorized to each other and to the network prior to the 
establishment of any logical connections. These mechanisms are examples of a multi-layered approach to 
communications security (Ref. 1 7). 

A comprehensive communications network security approach involves a layered scheme to ensure the 
protection of the network at multiple layers. Commonly referred to as “Defense-in-Depth,” a layered 
security approach eliminates a single point of failure and relies on a continuous security policy, security 
training for its users, as well as the application of the appropriate technology to ensure the following: 

• Confidentiality — protection from eavesdropping 

• Integrity — user and management data is not modified while in transit 

• Authentication — assurance that users and devices can authenticate each other 

• Authorization — mechanism that verifies user and AeroMACS service associations 

• Access Control — control authorized access to network resources 

• Availability — prevent Denial of Service or of the AeroMACS network and its attendant 
resources. 

Security in a communications network should be deployed at multiple levels to eliminate potential 
single points of failure. The 802.16-2009 standard defines a number of security enhancements that 
provide defense-in-depth to ensure confidentiality, authentication, authorization and integrity in addition 
to access controls for the communications infrastructure. They include the use of the Internet Engineering 
Task Force (IETF) extensible authentication protocol (EAP)-based AAA framework, used for mutual 
authentication and authorization of network elements and subscribers 

The AAA framework is also utilized for service flow authorization, QoS policy control, and 
encryption. IEEE 802.16-2009 specifies 128-bit encryption at a minimum. Encryption is used to ensure 
the confidentiality and integrity protection of both management and data traffic. As an added measure of 
protection, the Federal Government mandates the use of FIPS-approved cryptographic algorithms 
contained in FIPS-validated cryptographic modules. 

In addition, the WiMAX Forum specifies a range of security mechanisms that compliment the IEEE 
802.16-2009 PHY and MAC layer security mechanisms. Solutions include the deployment of VPN 
technologies to provide end-to-end encryption of the data channels at the network layer. Further, the 
development of security policies that incorporate physical and administration controls with the logical 
technology controls will ensure that the NAS ConOps requirements will operate in a reliable, resilient, 
secure AeroMACS infrastructure. 


NASA/CR — 201 1-216997/VOL1 xxviii 



The complete security assessment of AeroMACS is out of the scope of this report and is being 
addressed by NASA in a separate document (Ref. 18). 

ES.6 Introduction to Volume II 

Volume 11 describes modifications to the NASA Glenn Research Center (Glenn)/ Cleveland Hopkins 
International Airport (NASA-CLE) Communications, Navigation, and Surveillance (CNS) Test Bed to 
add Institute of Electrical and Electronics Engineering (IEEE) 802.16 (Ref. 19) capability and testing and 
evaluation results using simulation, emulation, and or experimentation and testing. It also provides initial 
data to be input to the aeronautical mobile-specific IEEE 802. 16 design specifications. 

Developing an AeroMACS solution based on the IEEE 802. 16-2009 standard requires detailed 
analysis, simulation, and test measurements on actual airport surfaces. This AeroMACS prototype in the 
NASA CLE CNS Test Bed is designed to implement many of the AeroMACS features and requirements 
that support modem data communications at an operational airport to help verify the performance of 
AeroMACS and validate some of the ConUse. 

Figure ES-6 shows the placement of the AeroMACS Prototype network on Glenn property and the 
adjacent CLE airport surface. 

NAS growth and improvement will provide continued safety, efficiency, and reliability to the flying 
public. The AeroMACS solution is designed to help increase airports’ capacity for departures and 
arrivals, as well as the safety and efficiency of surface movement, the security and flexibility of airport 
surface operations, and the situational awareness for airport surface users and stakeholders. AeroMACS 
will also help reduce delays, fuel consumption, and emissions. Finally, AeroMACS will be developed in 
cooperation with the European Organisation for the Safety of Air Navigation (EUROCONTROL) to 
advance the establishment of global standards and interoperability to effectively and efficiently enable 
rapid and thorough airport improvements as new applications augment and replace legacy systems. 



Figure ES-6. — NASA-CLE CNS Test Bed base station, backhaul, and core server locations. 

Acronyms are defined in Appendix A. 
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Special committee SC-223 was established within the RTCA aviation industry consortium to 
establish standards for AeroMACS. The principal products of this special committee are a set of final 
recommendations for a system profile to be delivered in September 2010 and a Minimum Operational 
Performance Standards (MOPS) document to be delivered in December 2011 (Ref. 20). 
EUROCONTROL established a similar work group, WG-82, that is chartered to develop an AeroMACS 
profile. SC-223 and WG-82 work cooperatively to develop a common profile document that will be 
provided as recommendations for consideration by ICAO. 

Sets of system parameter profiles have been recommended for AeroMACS within this study. These 
profiles are based on the existing IEEE 802.16-2009 standard. A profile working group within RTCA 
SC-223 is tasked with further developing the AeroMACS profile and deciding whether parameters are 
mandatory or optional to implement. 
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1.0 Introduction 

1.1 Background 

During the past five years, the NASA Glenn Research Center (Glenn) and ITT Corporation have 
conducted a three-phase technology assessment for the Federal Aviation Administration (FAA) under a 
joint FAA-European Organisation for the Safety of Air Navigation (EUROCONTROL) Cooperative 
Research Action Plan (AP-17), also known as the Future Communications Study (FCS). NASA Glenn, 
with the contracted support of ITT, provided a system engineering evaluation of candidate technologies 
for the future communications infrastructure (FCI) to be used in air traffic management (ATM). Specific 
recommendations for data communications technologies in the very high frequency (VHF), C, L, and 
satellite bands, and a set of follow-on research and implementation actions have been endorsed by the 
FAA, EUROCONTROL, and the International Civil Aviation Organization (ICAO). In the United States, 
the recommendations from AP-17 are reflected in the Joint Planning and Development Office’s (JPDO) 
“Next Generation Air Transportation System, Integrated Plan” (Ref. 21) and are represented in the 
“National Airspace System (NAS) Infrastructure Roadmaps” (Ref. 22). 

Action Plan 30 (AP-30), a proposed follow-on cooperative research to AP-17, ensures coordinated 
development of FCI to help enable the advanced ATM concepts of operation (ConOps) envisioned for 
both the Next Generation Air Transportation System (NextGen) in the United States and 
EUROCONTROL’s Single European Sky ATM Research program in Europe. Follow-on research and 
technology development recommended by ITT and Glenn and endorsed by the FAA was included in the 
FAA’s NextGen Implementation Plan 2009. The plan was officially released at the NextGen Web site 
( http://www.faa.gov/about/initiatives/nextgen/ ) on January 30, 2009. The implementation plan includes a 
FY09 solution set work plan for C-band and L-band future communications research in the section, “New 
Air Traffic Management (ATM) Requirements.” 

On February 27, 2009, the FAA approved a project-level agreement (PLA FY09_GlM.02-02vl) for 
“New ATM Requirements — Future Communications,” to perform the FY09 portion of the FAA’s 
solution-set work plan; this includes the development of concepts of use (ConUse), requirements, and 
architecture for both a new C-band airport surface wireless communications system and a new L-band 
terrestrial en route communications system. On February 1, 2010, the FAA approved the follow-on PLA 
(FY10G1M02- 02) to provide findings and recommendations to the RTCA and EUROCAE WG-82 on 
the aviation profile of the IEEE-802. 16e (WiMAX) based standard for an aeronautical mobile airport 
communications system (AeroMACS), and to complete evaluation of a proposed L-band digital 
aeronautical communications system (L-DACS) in relevant environments to support new en route ATM 
requirements. The work described in this report covers ITT’s portion of the PLA tasks related to C-band 
airport surface wireless communications development. The L-band portions of the PLA research are 
documented in a companion report (Ref. 23). 

This report is being provided as part of the Glenn Contract NNC05CA85C, Task 7: “New ATM 
Requirements — Future Communications, C-Band and L-Band Communications Standard Development.” 
Task 7 is separated into two distinct subtasks, each aligned with specific work elements and deliverable 
items identified in the FAA’s project-level agreement and with the FAA FY09 and FY10 spending plan 
for these subtasks. The purpose of subtask 7-1, and the subject of this report, is to define the C-band 
airport surface ConUse, systems performance requirements, and architecture in a future C-band (5091 to 
5150 MHz 4 ) air-to-ground (A/G) communication system referred to as the Aeronautical Mobile Airport 
Communications System (AeroMACS). 

The work is being performed in two phases. This report builds on the Phase I results presented in the 
Phase I report (Ref. 1 ). 


4 With a possible future extension into the 5000- to 5030-MHz band, pending a decision at the World 
Radiocommunications Conference in 2012. 
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The Phase II document is separated into two volumes. Volume I is devoted to the concepts of use, 
system requirements and architecture and provides some additional detail for the concepts developed 
during Phase I. New studies conducted during Phase II, including airport categorization and 
channelization methodology, and expand the AeroMACS design considerations section. Volume II 
document describes Phase II work to validate performance AeroMACS requirements and candidate 
architecture through test and evaluation of an AeroMACS prototype network built by ITT in the NASA- 
Glenn Test Bed. A description of the AeroMACS prototype network is provided, followed by 
descriptions and results of tests that evaluate AeroMACS performance using the prototype network. Final 
AeroMACS standards recommendations are provided. 

1.2 Systems Overview 

Systems covered by this document provide the following airport surface communications services 
shown within the dashed red boxes in Figure 1. 
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Operator System Element 




Figure 1. — Communications systems covered by this ConUse document (slightly altered version of 

Figure 1-1 in Ref. 7). 


• Air traffic services (ATS) A/G flight safety communications between fixed ATS provider (ATSP) 
system elements and an aircraft 

• ATS ground-to-ground (G/G) communications between fixed ATSP system elements (e.g., to 
provide connectivity between the components of a NAS surveillance system). 

• G/G communications between fixed and mobile operator (e.g., airline) system elements (e.g., to 
provide connectivity for aeronautical operational or administrative messages supporting the 
operation or maintenance of facilities provided for the regularity of aircraft operations as 
described in Ref. 24). 


On the ground, these systems typically consist of radio ground station subsystems — including radios, 
antennas, cabling, power systems, environmental systems, towers, monitoring and control functionality, 
and other systems to provide wireless communications services; networking subsystems to provide G/G 
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communications service connectivity to end systems and users; and usually some centralized functionality 
to monitor and control system operations and performance. Aircraft and other mobile components include 
radio equipment, antennas, and associated cabling. 


1.3 Document Overview 

This document is organized as follows: 

• Section 1 .0 provides background system information and describes the document scope, 
organization, and references. 

• Section 2.0 presents the processes for developing the ConUse and the requirements. 

• Section 3.0 is devoted to the ConUse of the proposed AeroMACS. After describing the ConUse 
development process, it presents the operational need for AeroMACS by describing current A/G 
and G/G communications systems and their associated problems and capability shortfalls. 

Section 3.3 shows the potential benefits of the new systems and describes the desired changes. 
The proposed system is then described. ConUse are presented, along with references to RTCA’s 
NAS concept of operations (ConOps) guidance documents and descriptions of FAA’s Data 
Communications Program (Data Comm) operational scenarios, NextGen operational concepts, 
and AeroMACS operational concepts based on the airport surface flight domain as well as those 
derived from the communications operating concept and requirements (COCR). 

• Section 4.0 presents preliminary AeroMACS network requirements. It describes the development 
process for system requirements and presents results for the “middle-out” approach. 

• Section 5.0 describes initial network architecture. 

• Section 6.0 presents AeroMACS design considerations. 

• Section 7.0 introduces the second volume of the report. 

• Appendix A defines acronyms and abbreviations used in this report. 

• Appendix B summarizes the RTCA NAS ConOps applicable to the proposed AeroMACS. 

• Appendix C provides hierarchical diagrams of the functional requirements for the AeroMACS 
C-band communication system. 

• Appendix D shows examples of airport categories based on propagation characteristics 

• Appendix E shows RTCA SC-223 USAS Workbook Summary 
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2.0 ConUse and Requirements Development Processes 

Multiple documents related to concepts of use and concepts of operations of the future data 
communication systems exist. This section provides background information related to ConUse and 
requirements development to offer the appropriate frame of reference and provide traceability to better 
define the scope of this report and its place in the family of concepts documents. 

ConUse are part of a hierarchy of documents that capture concepts related to the NAS. As defined in 
the FAA’s NAS System Engineering Manual (SEM), there are two general types of concepts documents 
associated with system engineering in the NAS: ConOps and ConUse. ConOps describe “what is 
expected from the system, including its various modes of operation and time-critical parameters” (Ref. 2), 
whereas a ConUse is “an extension of a higher level ConOps with an emphasis on a particular NAS 
system and its operating environment” (Ref. 2). Figure 2 depicts the three hierarchical levels of concept 
documents typically used in the NAS and defined in the SEM: two levels of ConOps and the ConUse. 



Figure 2. — National Airspace System (NAS) engineering concept document hierarchy (Ref. 2). Acronyms are 
defined in Appendix A. 
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These three levels can be summarized as follows: 


• NAS -level ConOps comprise “a high-level narrative of the user community’s desired change with 
some performance indicators. The document indicates from the user’s perspective the desired 
end-state for respective systems in the NAS. It often uses various operational scenarios to 
illustrate the desired operational concept” (Ref. 2). 

• Service-level ConOps provide “conceptual insight into a particular service of the NAS.” These 
give “more detail and in-depth information about the desired operations within the service” 

(Ref. 20). 

• ConUse are extensions of the NAS-level ConOps and a particular service-level ConOps, “with an 
emphasis on a particular NAS system and its operating environment.” ConUse are more detailed 
and substantial, but they still express “the user’s needs regarding a specific system within the 
NAS” (Ref. 2). 

NAS-level and similar level international ConOps driving this ConUse and its associated 
requirements include RTCA’s “National Airspace System: Concept of Operations and Vision for the 
Future of Aviation” (Ref. 14), the “Concept of Operations for the Next Generation Air Transportation 
System” (Ref. 4), and the ICAO’s “Global Air Traffic Management Operational Concept” (Ref. 25). At 
the next lower layer, EUROCONTROL’s “Operating Concept of the Mobile Aviation Communication 
Infrastructure Supporting ATM Beyond 2015” (Ref. 26) was used with the service-level ConOps — 
“Communications Operating Concept and Requirements for the Future Radio System (COCR)” 

(Ref. 1 1 ) — to provide reference guidance for A/G operating concepts and requirements directly applicable 
to this ConUse. On a similar level to this ConUse, but with a different scope and intended for different 
services, are the operating concepts and requirements presented in “Data Communications Safety and 
Performance Requirements” (Ref. 27) and “Final Program Requirements for Data Communications” 

(Ref. 5). 

It should be noted that the ConOps and ConUse documents just referenced relate primarily to the 
provision of safety-critical A/G air traffic control (ATC) communications services; however, they also are 
applicable to the provision of airport surface G/G communications links that support other NAS safety 
critical services, such as surveillance, weather, flight planning, and aeronautical information. NAS 
ConOps applicable to the provision of aeronautical operational and administrative messages over G/G 
communications systems and supporting the regularity of flight operations are not available for reference, 
perhaps because NAS ConOps typically apply to the provision and operation of safety-critical services. 

The ConUse and performance requirements described in this document apply to a future airport 
surface-band (5091- to 5150-MFIz) communication system referred to as AeroMACS that will provide 
A/G and G/G communications services similar in scope to those described in the “FC1 Aeronautical Data 
Services Definition Task Report” (Ref. 9) as well as other services shown in Figure 1. The 2009 FC1 
report follows from the previous FCS technology evaluation study (Ref. 28), which identified the IEEE 
802. 16e standard (Ref. 19), now included in the IEEE 802.16-2009 standard, as the recommended 
candidate for further development because it best meets the FCS technology assessment criteria and is 
designed for the C-band spectrum, which is a recommended band for supporting new data link 
communications capabilities for airport surface communications. 

Because many, if not most, NAS systems are not entirely new, but rather, evolutionary improvements 
of existing NAS systems, a top-down process is not always sufficient. Instead, a “middle-out” approach is 
taken. This is a combination of a top-down process, which takes into account new concepts and missions 
needs, and a bottoms-up approach, which takes into account existing concepts, systems, and requirements. 

Figure 3 shows the middle-out approach adopted for the ConUse and requirements developed for 
AeroMACS. As shown in the figure, operational concepts and requirements of higher level concepts 
documents flow down to this document, providing high-level guidance and direction in the form of 
required functions and flows for the services of interest, namely A/G and G/G communications services. 
In addition to this top-down process, a bottom-up process of identifying and evaluating specific concepts 
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and requirements developed for specific communications systems, such as Data Comm, Next Generation 
Air/Ground Communication (NEXCOM), and Link 2000+, along with appropriate NAS System 
Requirements (SR-1000, Ref. 13) and IEEE 802.16-2009 requirements (Ref. 15), was employed for this 
document. 
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3.0 ConUse 

3.1 ConUse Development Process 

A process recommended in the NAS system engineering manual (SEM, Ref. 2) was used as a guide in 
developing ConUse for the proposed AeroMACS. Figure 4 summarizes the steps. The following sections 
describe the findings for each of the steps shown in the figure. 
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Figure 4. — ConUse development process. Acronyms are defined in Appendix A. 


3.2 Operational Needs 

This section defines the operational needs for AeroMACS by describing current and planned airport 
surface communications systems and their associated problems and capability shortfalls. Though not a 
current system, the planned data communications networks services A/G data communications system 
being developed under the FAA’s Data Comm Program is discussed here because its initial 
implementation is expected to precede A/G AeroMACS on an airport surface. Data Comm should 
mitigate many of the current operational problems and shortcomings while leaving room for AeroMACS 
to provide additional gains in overcoming current A/G communications shortcomings. 
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3.2.1 Current Airport Surface Communications Systems 

3.2. 1.1 Current Air-to-Ground Communication System 

The “System Requirements Document, Next Generation Air/Ground Communications (NEXCOM)” 
provides a good description of the FAA’s current analog A/G voice communications system used for 
ATC (Ref. 3): 

The current A/G Communications System for ATC consists of voice-based networks that use 
DSB-AM [double-sideband amplitude-modulation] radios and operate in the 117.975 to 
137 Megahertz (MHz) VHF band for civil aircraft and the 225- to 400-MHz UHF [ultra-high- 
frequency] band for military aircraft. The radios operate with the same frequency used for controller- 
to-pilot (uplink, UL) and pilot-to-controller (downlink, DL) transmissions in a simplex “push-to-talk” 
mode. There is a dedicated, non-interconnected radio network for each operational environment 
(EnRoute, Terminal, airport surface, and flight service). In the event of a control facility power loss, 
engine generators provide back-up power. In the event of equipment failure, A/G communications 
are provided Back-Up Emergency Communications (BUEC) in the En route, Emergency 
Communications System (ECS) in the large TRACONS [terminal radar approach control facilities] 
and portable transceivers in the smaller TRACONS and Air Traffic Control Towers (ATCT). 

The current A/G communications system architecture is roughly the same for all operational 
environments. The specific equipment used in the A/G communications string can differ among the 
various facilities. Different control facility types have different voice switches, with each type of 
switch having a unique interface. 

Figure 5 shows this system for en route A/G communications. Similar architectures are in place for 
terminal area and airport surface area A/G communications. Figure 6 depicts a typical remote 
transmitter/receiver (RTR) site configuration used for A/G communications for the terminal area and for 
the airport surface. Appendix A of the NEXCOM System Requirements Document provides a detailed 
description of the current A/G voice communications architecture and facilities. 
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Figure 5. — Current en route air-to-ground (A/G) communications system (Ref. 3). Acronyms are defined in Appendix A. 
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Figure 6. — Typical remote transmitter/receiver (RTR) site configuration (Ref. 3); air traffic control tower (ATCT). 
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3.2. 1.2 Current Airport Surface Ground-to-Ground Communication Systems 

Current G/G communications on the airport surface are conducted predominantly over a combination 
of wire and optical fiber cabling and a limited number of point-to-point line-of-sight (LOS) radio links. 
Most often, airport surface systems are interconnected by direct telecommunications services, including 
underground cable systems implemented by the airport. 

Shielded, twisted-pair copper lines carry low-data-rate and voice communications between fixed 
locations. Fiber-optic cables perform a similar function but have expanded bandwidth capability. Point-to- 
point radio links can handle narrow to wide data bandwidths without the use of difficult-to-install 
underground cables. 

G/G communications handle data exchanges between a wide variety of applications on the airport 
surface. Table 1 lists examples of present and future applications that require G/G communications. 


TABLE 1.— AIRPORT SURFACE SYSTEMS THAT COULD BE SUPPORTED BY AEROMACS 


Service 

Airport Surface Systems Supported 

Sensor data collection/dissemination for 
situational awareness 

Multilateration (MLAT) Airport Surface Detection Equipment, Model X 
Automatic dependent surveillance — broadcast (ADS-B) ground sites 
Air surveillance radar 
Airport lighting systems 

Network-enabled weather data; automated surface observation systems 
(ASOS), low-level wind shear alert system. Terminal Doppler Weather 
Radar, Integrated Terminal Weather System, icing 

Cable/Telco replacement and 
augmentation 

Backup and primary alternative to cabled connections 
Extend cable loop infrastructure to remote surface assets 

Temporary fixed-asset connection during surface construction or service 
restoration 

Remote transmitter/receivers (RTRs) 

Remote maintenance and monitoring 


3.2.2 Current System Operational Environments 

Rather than being a NAS service itself, G/G and A/G communications are enablers of NAS services 
and provide the following functionality (Ref. 13): 

Communications enables the NAS to exchange information with users, specialists, ATC facilities, and 
other Government agencies. Communications enables air traffic control operations within the NAS by 
employing appropriate technologies to exchange voice and data. This information is transported over 
land lines and wireless connectivity utilizing government and commercial assets. Communications 
defines how data is moved across the NAS to accomplish flight planning, control functions and 
navigation services for ground and space-based systems. This enabler provides end-to-end service to 
pilots to include disseminating and coordinating the flight plan and defines how controllers provide 
service throughout the flight while coordinating with other facilities and government agencies. The 
communications enabler supports collaboration between users and specialists for traffic 
synchronization and flow services. Communications support the exchange of navigation and 
surveillance information across the NAS. Information includes electronic signals emanating from 1LS 
[instrument landing system], VOR [VHF omnidirectional range] and space-based systems and aircraft 
transmitted beacon code data. 
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Reference 29, which gives an As-Is System View 2 (SV-2) of the NAS, describes how NAS 
interfaces, as identified in Reference 13 (NAS SV-1) are supported by physical media. 

Pertinent information about communications systems, communications links, and communications 
networks is presented as a pictorial view of system interactions and telecommunications service 
characteristics along with implementation technologies. The As-ls SV-2 figures were developed 
depicting an overall telecommunications infrastructure and providing separate views for five information 
flow areas: 


• Surveillance 

• Weather 

• Command and control 

• Flight data 

• Aeronautical information 

3.2.2. 1 Current Air Traffic Control Air-to-Ground Communications System Operational 
Environments 

Figure 7 presents an overview chart depicting an SV-2 telecommunications view and associated data 
for the command and control functional flow area. Note that the “Terminal Voice” link depicted in the 
figure also would include airport surface voice communications between aircraft on the ground and radio 
equipment (typically RTR sites, as shown in Figure 8) serving ATCTs. 



Figure 7. — System View 2 (SV-2) command and control detailed air-to-ground communications 
view for 2009 to 201 0 (Ref. 29). Acronyms are defined in Appendix A. 
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Specifically, A/G communications is mainly used for communications between air traffic controllers 
or specialists on the ground and manned aircraft pilots to enable the following required NAS functions 
(Ref. 13) 5 : 

• Manage flight plans (plan flights) 

• Monitor aircraft status (monitor flights) 

• Control aircraft (control traffic) 

• Manage weather information (support flight operations) 

• Maintain NAS infrastructure (monitor NAS operations) 

• Plan traffic flow (plan NAS usage) 

• Assess traffic flow performance (plan NAS usage) 


For the most part, these functions are currently implemented in the NAS via voice communications; 
though the NAS SR- 1000 (Ref. 13) includes requirements for some functions that explicitly designate 
data communications as the means of A/G communications and other requirements that do not specify the 
A/G communications type. 

The NAS functions listed above are needed to provide several of the NAS service capabilities defined 
in the NAS SR-1000. Table 2 provides a mapping of NAS-level functions to the NAS service capabilities 
enabled by those functions. An “x” at a row-column intersection in the table indicates that the particular 
function in that row is needed to provide the NAS service capability in that column. Of particular interest 
for this report are the functions that can be enabled by A/G voice communications to provide specific 
NAS service capabilities. For example, A/G voice communications is used to implement some of the 
functionality needed to manage flight plans in support of the flight-planning service capability. This A/G 
voice-communications-specific mapping is indicated by the blue boxes in the table. Thus, as shown in the 
table, A/G communications is needed to support the following NAS service capabilities (denoted with 
blue boxes in the service “Capability” row): 

• Flight planning 

• Separation assurance 

• Advisory services 

• Traffic flow management 

• Emergency services 

• Infrastructure and information management 

Some of the NAS service capabilities listed earlier, such as separation assurance and A/G- 
communications-enabled flight planning service capability, are considered to be safety critical for the 
NAS. Because of the need to support such NAS critical services, A/G voice communications latency and 
availability performance requirements are fairly stringent. Typically, this has resulted in requirements for 
0.99999 availability (so-called, 5-9s) and an end-to-end latency of 250 msec 6 for the most critical voice 
communications services. 

For continental airspace, A/G voice communications is provided in the terminal maneuvering area 
(TMA), en route, and in airport surface domains, with the current architecture as described in 
Section 3.2.1. Voice communications is used for all phases of flight: that is, from gate to gate. 


5 ln the listing, the subfunction is shown, followed by the parent function in parentheses. 

6 This performance value for end-to-end A/G voice communications latency was provided in earlier versions of NAS 
SR-1000, but is not in current versions. 


NASA/CR — 201 1-216997/VOL1 


13 



TABLE 2.— MAPPING AIR-TO-GROUND VOICE COMMUNICATIONS FUNCTIONS 
TO NATIONAL AIRSPACE SYSTEM (NAS) SERVICE CAPABILITIES (REF. 13) 
[Acronyms are defined in Appendix A.] 
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3.2.2.2 Current Airport Surface Ground-to-Ground Communications System Operational 
Environments 

Besides the various NAS service capabilities and functions enabled by A/G communications for 
command and control as described in the preceding section, numerous surveillance, weather, and 
aeronautical data NAS services are supported by systems operating on the airport surface. For the most 
part, these systems are interconnected by direct telecommunications services, including underground 
cable systems implemented at the airport. The NAS services potentially supported by systems operating 
on the airport surface are indicated by red dashed boxes in Figure 8. 
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3.2.3 Current System Users 

The users of the current VHF A/G and G/G communications systems include the following (Ref. 30): 

(1) Scheduled air transport carriers (including international, trunk, regional, commuter, and air 
freight carriers) 

(2) Nonscheduled air carriers 

(3) General aviation (including operators of turbine-powered and reciprocating-engine aircraft) 

(4) Operators of unpowered aircraft (including gliders and lighter-than-air aircraft) 

(5) Operators of various military aircraft 

(6) Operators of certain ground and maritime vehicles (e.g., airport service vehicles and those 
vehicles coordinating in a search-and-rescue mission) 

(7) ATS providers 

(8) Aeronautical operational control (AOC) service providers 

3.2.4 Current System Scope and Capability Shortfalls 

3.2.4.1 Current Air Traffic Control Air-to-Ground Communications System Scope and 
Capability Shortfalls 

The objectives of the current A/G communications system are consistent with the provisions of the 
NAS service capabilities and performance requirements listed in Section 3.2.2. 1. Currently, they are 
characterized by (Ref. 11), “high availability, low end-to-end latencies, the ability to convey human 
feelings, flexibility of dialogue, provision of a party-line, and use for nonroutine, time-critical, or 
emergency situations.” 

Some of these characteristics actually offer an advantage to voice communications as compared to 
data communications; however, there are several disadvantages of voice communications that motivate 
the need for data communications for many applications. 

The NextGen ConOps has summarized the current attributes (and associated constraints) of the voice- 
based A/G communications system as follows (Ref. 4): 

• Limited data communications for ATM and operational control 

• Limited access to real-time weather and aeronautical data 

• Voice communications routine for ATM 

• Analog voice 

• Analog weather information display systems 

• A/G and G/G communications 

• Loss of communications due to beyond line-of-sight (BLOS) aircraft position (e.g., over the 
ocean) 

• Individual ground systems for each information type brought to the flight deck 

• Point-to-point aircraft communications based on ATC sectors 

Currently continental A/G voice communications systems operate over the VHF and UHF 
aeronautical mobile (route) service (AM(R)S) frequency bands, and the scope of operation is constrained 
to be radio LOS, which dictates the need for networks of ground radio stations to provide radiofrequency 
(RF) coverage for the entire airspace volume for which the NAS service is to be provided. 

Current system limitations also include spectrum constrains, nonsecure communications, and 
susceptibility to noise. 
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Figure 9 summarizes several principal shortcomings of the current A/G voice communications 
system, including lack of automation, limited or no data communications availability, aging infra- 
structure, technology limitations, and spectrum saturation. The resulting operational problems, if not 
addressed, could lead to service degradation and limit the introduction of new or expanded services. 
These, in turn, could potentially compromise safety of operation and increase operating costs. 
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Figure 9. — Current National Airspace System air-to-ground communications operational problems. 


Though saturation of spectrum is highlighted in red as the problem specifically mitigated by the 
introduction of a new C-band system (AeroMACS); the other operational problems would also be 
mitigated with AeroMACS. 

As the NAS evolves to achieve the JPDO’s and FAA’s NextGen vision and ConUse, many of the 
transformational services and planned operational improvements will be enabled via data communi- 
cations. Unfortunately, the current A/G communications system lacks data communications capability for 
ATS. In moving toward NextGen, this shortcoming will become more acute and will lead to several 
significant shortfalls in safety, capacity, efficiency, and productivity. As part of the investment analysis 
process for Data Comm, a fairly comprehensive list of these shortfalls has been developed. These are 
repeated in Table 3 to specifically identify the shortfalls that Data Comm intends to address. 

It is important to note that the “Final Program Requirements for Data Communications” (Ref. 5) 
recognizes that “the scope of the mission shortfalls identified herein is broader than will be addressed 
solely by a data communications capability.” Because of the limitations and constraints of implementing 
data communications using very high frequency digital link (VDL) Mode 2 over a congested aeronautical 
VHF band, Data Comm will focus principally on implementing the most critical air traffic services. This 
provides opportunities for AeroMACS network to augment data communications on the airport surface by 
enabling communications of less critical and essential air traffic services to address the shortfalls listed in 
Table 3. 
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Even though Data Comm means to use VDL Mode 2 to address, to some extent, each of the shortfalls 
in Table 3, there are opportunities to overcome these shortfalls to even a greater extent during the later 
program segments of Data Comm (e.g., late Segment 2 and Segment 3) using link technologies such as 
AeroMACS with greater bandwidth capabilities, which could augment the benefits already attained 
through the earlier VDL Mode 2 Data Comm segment implementations (i.e., Segments 1 and 2) by 
providing a broader scope of services. 

TABLE 3.— CURRENT SHORTFALLS RELATED TO AIRPORT SURFACE AIR-TO-GROUND VOICE 

COMMUNICATIONS 

[From a subset of the shortfalls described in Ref. 31.] 

Safety shortfalls 

Situations conducive to producing errors, confusion, and read-back and hear-back errors arising from voice congestion and voice 
communication quality 

No alternative means to enable A/G communication support for contingency plans when the primary voice communication is not 
available 

Capacity shortfalls 

Inability to rapidly and accurately communicate complex clearances containing multiple latitude/longitude-defined route 
elements 

Inefficient dissemination of airspace congestion, weather advisory, and NAS infrastructure status information 

Inefficient communication of complete departure clearances and revisions necessitated by traffic management initiatives 

Inability to provide for the maximum efficient use of the airspace and strategic plans by adjusting individual flights to reduce 
contention for resources and ensure that no resource is allowed to remain idle in the face of demand 

Limited ability to use four-dimensional trajectories associated with flight objects and the airspace plan to identify areas of 
congestion, and the potential need for flow control initiatives to mitigate severe congestion 

Efficiency and productivity shortfalls 

Inability to support airspace user operational requirements, utility, performance, and other flight operations preferences — 
Avionics and airframe manufacturers need consistent global communication capability requirements. 

Inability to exchange user-preferred trajectories in real time; limited decision-support tools to communicate and ensure user 
preferred routing, integrated sequencing, and spacing of arrivals and departures in terminal radar approach control (TRACON) 
airspace 

No synchronization between onboard avionics, such as flight management systems, with ground flight data processing systems — 
Lack of synchronization between airborne and ground-based ATC increases controller and flight crew workload, imposes 
additional communications requirements, and introduces risks of operational errors and incidents. Providing for synchronization 
between aircraft flight management systems and ground-based ATC data-processing systems would increase predictability for 
flights and allow aircraft operators to reduce costs, optimize flight routes, improve utility, and reduce dependency on voice 
communications. 

No integration of A/G communications with other aspects of the automation environment — 

Instructions to and requests from airspace users must be independently exchanged via voice A/G communications and then 
manually updated in automation systems such as the flight data processor leading to system errors and less efficient movement of 
aircraft through the airspace. 

Inability to automate many repetitive and time-consuming tasks; precludes labor resources from focusing on more productive 
tasks. 

No capabilities inherent in modern, network-based communications; therefore, less efficient dynamic resource management 
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3.2.4.2 Current Airport Surface Ground-to-Ground Communications Systems Scope and 
Capabilities Shortfalls 

The existing airport communications infrastructure lacks the flexibility for reconfiguration and for 
accepting new services because of its limited bandwidth and interface capabilities. In addition, many 
control, signal, and communications cables serving FAA facilities at major airports are 25 to 30 years old. 
In many cases, the cables are badly deteriorated, lack remote maintenance monitoring functions, and do 
not provide redundant paths for critical functions. Underground cables are also at risk from inadvertent 
“cable cuts” and are vulnerable to surges due to lightning strikes. It is expensive to deploy and maintain 
underground cabling as a replacement for existing cables or an expansion for new services. 

The limitations imposed by the current G/G communications infrastructure could result in restrictions 
in the deployment of new ATM services, leading to the following service limitations (Ref. 4): 

• Limited ATM (e.g., traffic) information on the flight deck 

• Limited data shared among stakeholders for collaborative decision making (CDM) processes 

• Information sharing in support of operational security performed manually instead of 
electronically 

• Not all stakeholders able to access data they need 

• Stakeholders unable to use custom data sources 

3.3 New Airport Surface Communications Systems Justification 

3.3.1 Potential Benefits of New Airport Surface Communications Systems 

3.3. 1.1 Potential Benefits of New Airport Surface Air-to-Ground Air Traffic Control 
Communications Systems 

The NextGen ConOps states that transforming the ATM system in NextGen is “necessary because of 
the inherent limitations of today’s system, including limits driven by human cognitive processes and 
verbal communications” (Ref. 4). Likewise, the joint EUROCONTROL/FAA FCS conducted for AP-17 
concluded that “in the longer term, a paradigm shift will occur in the operating concept and the prime 
mode of communication exchanges will be based in data exchanges rather than voice communications as 
it is today” (Ref. 31). 

The following excerpts (Ref.4) from JPDO’s NextGen ConOps comprehensively describe NextGen 
A/G network services. These excerpts are repeated here because they effectively communicate the full 
envisioned scope, benefits, and advantages of these services and the importance of data communications 
in enabling them: 


With the transformed role of the flight crew and flight deck in NextGen, data communications are 
critical to ensuring that data is available for flight deck automation (i.e., avionics to support flight 
crew decision making). . . . Data communications are also needed to provide real-time data to the 
ANSP [air navigation service provider] on the operational aspects of flights. In certain defined 
airspace, data communications are the primary means of communicating clearances, routine 
communications, and 4DT [four-dimensional trajectory: latitude, longitude, altitude, and time] 
agreements between the ANSP and flight deck. . . . Voice communications are used to supplement 
data communications for tactical situations and for emergencies to augment procedural responses or 
risk mitigations. Voice communications are used to communicate with lesser-equipped aircraft in 
appropriate airspace. . . . 

One of the key transformations is that air-ground voice communications are no longer limited by the 
assigned frequency-to-airspace sector mapping. This allows greater flexibility for developing and 
using airspace/traffic assignments in all airspace. Communications paths, including both voice and 
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data, are controlled by an intelligent network. Communications between the ANSP and the flight deck 
are established when the flight is activated and are maintained continuously and seamlessly. This 
capability is linked to the flight data management function so that the system automatically manages 
who has authority to interact with the flight deck based on the type of agreement being negotiated or 
information being exchanged. Labor-intensive transfers of control and communication are automated. 
Data and voice communications are automatically transferred in the flight deck as the aircraft moves 
between AN SPs. 

Data communications are central to TBO [trajectory-based operations], including the use of 4DTs 
(pushback and taxi inclusive) for planning and execution on the surface, automated trajectory analysis 
and separation assurance, and aircraft separation assurance applications that require flight crew 
situational awareness of the 4DTs and short-term intent of surrounding aircraft. 

In addition, as indicated above, there is increased sharing of improved common data between the 
flight deck, operator, and ANSP. In classic airspace where data communications will be available but 
not required, information exchange can take place with data communications for participating aircraft 
to provide an operational advantage. Common data includes ATC clearances, current and forecast 
weather, hazardous weather warnings, notices to airmen (NOTAMs), updated charts, current charting, 
special aircraft data, and other required data. Data communications also include weather observations 
made by the aircraft that are automatically provided to AN SPs, weather service providers, and flight 
operators for inclusion in weather analysis and forecasts. Each of these data communications 
functions are managed by required communications performance (RCP) standards. 


The trend toward 20 1 5 and beyond features a decreasing use of voice, with data becoming the 
primary communication link. This is shown in Table 4, which illustrates a projected allocation between 
voice and data communications during this period. As suggested by the table, on the airport surface, voice 
would remain the primary mode of communications for low delay and high availability pilot-ATC 
exchanges, with a data link used as a primary service for other messages and data-intensive services such 
as graphical weather. In all domains, voice communication would remain a backup for any data service. 


TABLE 4.— COMMUNICATION ALLOCATION BETWEEN VOICE AND DATA LINK (D/L) 

[Information from Ref. 32.] 




Airport surface ! 

Primary 

Backup 

Pilot-controller 

Emergency messages 

Voice 

D/L 

dialog 

Tactical clearances 

Voice and some D/L 

Voice and D/L 


Strategic clearances 

D/L 

Voice 


Infonnation messages 

D/L 

Voice 

Other 

Pilot-pilot dialog 

Voice 3 

D/L 

exchanges and 

Flight information exchange 

D/L 

Voice 

broadcasts 

Air traffic management exchange 

D/L 

Voice 


Infonnation broadcast 

D/L 

Voice 


Air-to-air surveillance 

D/L 



a No specific requirement identified except current Traffic Information Broadcast by Aircraft (TIB A) procedure. 


Although a gradual addition of data communications to the existing VHF voice systems should 
accommodate capacity requirements in the near term to midterm, additional spectrum is required to 
provide enough capacity to satisfy a growing demand for data communications in the far term. An 
AeroMACS built to augment VHF voice and data communications systems already in place, including 
those implemented as part of Data Comm, would increase overall communications system capacity, thus 
relieving congestion and allowing for the introduction of additional services. 
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3.3. 1.2 Potential Benefits of New Airport Surface Ground-to-Ground Communications Systems 

The benefits of a new broadband and networked airport surface G/G communications system are 
similar to those enabled by improved A/G communications in that common data can readily be provided 
to the flight planners and the flight deck. Current NAS modernization and the future NextGen air traffic 
system will increase the demands for CNS information sharing and standardization among stakeholders. 
An AeroMACS could provide the following benefits: 

• Standardized ATM information (e.g., surveillance and weather information) provided to the 
ANSP, flight deck, and aircraft operators 7 

• Information sharing among security stakeholders, facilitating collaboration, risk management, and 
decision making 

• Reliable and secure integration of voice, video, and data at all airport surface locations 

• System Wide Information Management (SWIM) networked integration of data sources and users 

• Flexible, expandable, and affordable delivery of needed information and services, independent of 
user physical location 

• Reduced VHF spectrum congestion 

3.3.2 Operational Shortfalls Addressed by Data Comm 

The FAA intends for Data Comm to significantly mitigate the safety, capacity, efficiency, and 
productivity shortfalls described in Table 3. It is anticipated that Data Comm will support the following 
improvements in airspace use and capacity (Ref. 5): 

• Improved airspace use and capacity 

• A more efficient A/G information and clearances exchange mechanism 

• An additional means of communication between flight crews and controllers 

• Reduced congestion on the voice channels 

• Reduced operational errors and flight crew deviations resulting from misunderstood clearances 
and read-back errors 

• Trajectory-based operations 

• Reduced controller and flight crew workload 

Data Comm is planned to be implemented in three segments (Ref. 5; see Figure 10): 

• The first segment will facilitate data communications deployment and introduce initial 4-D 
routes. 

• The second segment will introduce conformance management and initial 4— D agreements. 

• The third segment will expand 4-D agreements and provide an operational environment that 
allows the transfer of some separation assurance tasks from the ground to the air. 


7 G/G communications would provide connectivity between weather and surveillance sensors and associated network 
equipment, while an A/G link would provide the end product (e.g., weather or surveillance data) to the aircraft. 
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Figure 10. — Operational capabilities of Data Comm (Ref. 33). Acronyms are defined in Appendix A. 

An AeroMACS implementation in the United States might follow or overlap with Segment 2 VDL 
Mode 2 implementation and enable additional services and operational capabilities not covered by VDL 
Mode 2 for Data Comm. Figure 10 depicts the planned capabilities for Data Comm and, for comparison, 
the European planned deployment of data communications capabilities. Those operational capabilities and 
the associated services shown in the figure for Segment 3, for example, the services needed to provide 
widespread 4-D agreements (on the airport surface), might benefit from a higher performance technology 
implementation like AeroMACS. In addition to potentially augmenting the critical data communications 
services provided by VDL Mode 2 for Data Comm, AeroMACS could enable new noncritical services. 

Figure 1 1 provides additional detail about the data link evolution in Europe. The VDL Mode 2 
transition to the FCI shown in the figure demonstrates the potential difference between the U.S. and 
European approach to the data link development. Contrary to the European plan to transition many safety 
critical services to the FCI (AeroMACS), the U.S. is currently looking at AeroMACS to augment, not to 
replace, the VDL Mode 2 data link enabling the FAA Data Comm services. 
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Figure 1 1 . — Data Link Evolution (LINK 2000+ Update. AEEC DataLink Users Forum, 13-14 July 2010, 
Brussels.) Used with permission. 


3.3.3 Description of Desired Changes 

3.3.3. 1 Desired Changes for Air-to-Ground Air Traffic Control Communications Systems 

Data Comm will provide data communications as an enhancement to and potential replacement of 
A/G voice communications as the primary A/G link in an ATC operational environment. This additional 
mode of communications will contribute to improvements in airspace use and capacity. An AeroMACS 
could further reduce congestion on VHF voice channels and increase A/G communications capacity on 
the airport surface by offering spectrum for additional services not offered by Data Comm. With Data 
Comm and AeroMACS, the overall A/G information exchange could become more dynamic and 
efficient, potentially reducing operational errors and improving safety. 

For airport surface A/G ATC communications, AeroMACS is not proposed to replace any current 
systems or services; rather, it is intended to augment them. Furthermore, it is assumed that the critical 
services proposed for implementation by Data Comm as an addition and/or replacement of voice 
communication will be in place by the time A/G AeroMACS is implemented. 

The proposed AeroMACS is being designed to limit interference to the existing services and 
operations in the C-band. No operational changes are expected for C-band incumbent systems. 

3.3.3.2 Desired Changes for Airport Surface Ground-to-Ground Communications Systems 

The desired changes for G/G communications have many similarities to the changes desired for A/G 
communications by contributing to improvements in airspace use and capacity. Deployment of 
AeroMACS for G/G information exchange woidd augment and/or replace existing airport surface G/G 
communications systems by providing more flexible data exchange — new communications nodes could 
be added much more quickly and at significantly reduced costs in comparison to changes to the current 
cabled systems. Communications would become more dynamic and efficient, potentially reducing 
operational errors and improving safety. 
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3.3.4 Change Priorities and Roadmaps 

Figure 12 demonstrates how the C-band system development fits into the FCS proposed 
communications evolutional roadmap for European and U.S. ATM (as envisioned in 2007). 
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Figure 12. — Evolution overview of aeronautical mobile communications (Ref. 31; note that this schedule is 
subject to change). Acronyms are defined in Appendix A. 


Figure 13 depicts the proposed C-band (and L-band) communications systems far-term strategy as 
part of the NAS Enterprise Architecture Communication Infrastructure Roadmap. 
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Figure 13. — Federal Aviation Administration communications roadmap (Ref. 34). Acronyms are defined in 
Appendix A. 


3.3.5 Assumptions and Constraints for AeroMACS 

Assumptions and constraints for this document follow: 

• The 5091- to 5 150-MHz spectrum allocation for AeroMACS use at the World 
Radiocommunications Conference (WRC-2007) is provisioned only for use on the airport 
surface. This allocation is within the aeronautical mobile (route) service (AM(R)S) band. 
Therefore, AeroMACS applications are constrained to mobile applications on the airport surface. 
This is interpreted to include communications for nonmobile (i.e., fixed) applications provisioned 
within a mobile AeroMACS network that supports the safety and regularity of flight. 

• The proposed AeroMACS is assumed to provide an increase in overall A/G communications 
systems capacity by utilizing the new spectrum (i.e., in addition to existing VHF spectrum). 

• The scope of this ConUse and requirements report includes airport surface A/G communications 
and G/G communications. 

• AeroMACS will be designed specifically for data communication. Voice communication may be 
provided as a digital data communications service (e.g., VoIP). 

• This report assumes that the data communications system developed as part of the FAA Data 
Communications Program (Data Comm) will precede an A/G AeroMACS implementation and 
deployment. 
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• Although some critical services could be supported, AeroMACS networks will also target 
noncritical services, such as weather advisory and aeronautical information services implemented 
as part of an airborne access to SWIM program. 

• AeroMACS is to be designed and implemented in a manner that will not disrupt other existing 
services operating in the C-band. Additional interference research and testing will determine if 
any operational constraints are to be imposed, such as limiting the number of users, the time of 
the day, the duration, and so on. 

3.4 Proposed AeroMACS networks 

3.4.1 Objectives and Scope 

Consistent with the need to overcome the specific current communications system problems and 
shortfalls discussed earlier, the two primary general drivers for a future radio system are (1) “to provide 
an appropriate communications infrastructure to support future air traffic growth” and (2) “to provide a 
consistent global solution to support the goal of seamless air traffic management” (Ref. 11). Some FAA 
objectives defined in the FAA’s NextGen portfolio are based on the requirement to support future air 
traffic growth. AeroMACS will be designed and developed to help meet those objectives in part by 
expanding the data communications capacity in the airport surface domain. Global harmonization is being 
ensured by developing the proposed AeroMACS component of the FRS as a collaborative effort of the 
U.S. and European partners. 

3.4.1. 1 AeroMACS as Part of the Next Generation Air Transportation System 

Figure 14 illustrates the proposed NextGen operational view 1 (OV-1) in 2025, listing six of the 
seven solution sets of the FAA’s NextGen portfolio. 8 AeroMACS could fulfill part of the proposed 
NextGen vision by supporting implementation of the following solution sets: 

• Increase flexibility in the terminal environment 

• Initiate trajectory-based operations 

• Increase arrivals and departures at high-density airports 

• Improve collaborative ATM 

• Reduce weather impact 


8 The seventh solution set, not shown in the figure, is “safety, security, and environment. ” 
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Figure 14. — Next Generation Air Transportation System (NextGen) operational view in 2025 (Ref. 35). 
Acronyms are defined in Appendix A. 

The following subsections briefly describe the specific operational improvements (OIs) that could be 
enabled by AeroMACS for these three solution sets . 9 


9 These descriptions are extracted from the NAS Enterprise Architecture web portal (Ref. 24). 
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Increase flexibility in the terminal environment (excerpts from Ref. 34) 

102406 — Provide Full Surface Situation Information'. Automated broadcast of aircraft and 
vehicle position to ground and aircraft sensors/receivers provides a digital display of the airport 
environment. Aircraft and vehicles are identified and tracked to provide a full comprehensive picture 
of the surface environment to ANSP, equipped aircraft, and flight operations centers (FOCs). 

102409 — Provide Surface Situation to Pilots, Service Providers and Vehicle Operators for Near- 
Zero-Visibility Surface Operation : Aircraft and surface vehicle positions are displayed to aircraft, 
vehicle operators, and air navigation service providers (ANSP) to provide situational awareness in 
restricted visibility conditions, increasing efficiency of surface movement 

103206 — Expanded Traffic Advisory Services Using Digital Traffic Data: Surrounding traffic 
information is available to the flight deck, including automatic dependent surveillance (ADS) 
information and the rebroadcast of non-transmitting targets to equipped aircraft. Surveillance and 
traffic broadcast services improve situational awareness in the cockpit with more accurate and timely 
digital traffic data provided directly to aircraft avionics for display to the pilot. 

104207 — Enhanced Surface Traffic Operations: Data communication between aircraft and ANSP 
is used to exchange clearances, amendments, and requests. At specified airports, data 
communications is the principle means of communication between ANSP and equipped aircraft 

Initiate trajectory-based operations (excerpts from Ref 34) 

01 101103 — Provide Interactive Flight Planning From Anywhere: Flight planning activities are 
accomplished from the flight deck as readily as any location. Airborne and ground automation 
provide the capability to exchange flight planning information and negotiate flight trajectory contract 
amendments in near real-time. 

01 104121 — Automated Negotiation/Separation Management: Trajectory management is 
enhanced by separation management automation that negotiates with properly equipped aircraft and 
adjusts individual aircraft Four-Dimensional Trajectories (4DTs) to provide efficient trajectories, 
manage complexity, and ensure separation assurance. 

01 104126 — Trajectory-Based Management — Gate-To-Gate: All aircraft operating in high 
density airspace are managed by Four Dimensional Trajectory (4DT) in En Route climb, cruise, 
descent, and airport surface phases of flight to dramatically reduce the uncertainty of an aircraft's 
future flight path in terms of predicted spatial position (latitude, longitude, and altitude) and times 
along points in its path. 

Integrating separation assurance and traffic management time constraints (e.g., runway times of 
arrival or gate times of arrival), this end state of 4DTbased capability calculates and negotiates 4DTs, 
allows tactical adjustment of individual aircraft trajectories within a flow, resolves conflicts, and 
performs conformance monitoring by Air Navigation Service Providers (ANSPs) to more efficiently 
manage complexity, ensure separation assurance, and enhance capacity and throughput of high- 
density airspace to accommodate increased levels of demand. This will be enabled by the trajectory 
exchange through data communications, as well as many new surface automation and 3D (x, y, and 
time) trajectory operations. 

Increase arrivals and departures at high-density airports (excerpts from Ref 34) 

01 102153 — Limited Simultaneous Runway Occupancy: Runway capacity is increased through 
the allowance of more than one aircraft on the runway, at a given time, for specific situations. 

01 104117 — Improved Management of Arrival/Surface/Departure Flow Operations: This 
Operational Improvement (01) integrates advanced Arrival/Departure flow management with 
advanced Surface operation functions to improve overall airport capacity and efficiency. Air 
Navigation Service Provider (ANSP) automation uses arrival and departure -scheduling tools and four 
dimensional trajectory (4DT) agreements to flow traffic at high-density airports. Automation 
incorporates Traffic Management Initiatives (TMIs), current conditions (e.g., weather), airport 
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configuration, user provided gate assignments, requested runway, aircraft wake characteristics, and 
flight performance profiles. ANSP, flight planners, and airport operators monitor airport operational 
efficiency and make collaborative real-time adjustments to schedules and sequencing of aircraft to 
optimize throughput. 

01 104125 — Integrated Arrival/Departure and Surface Traffic Management for Metroplex: 
Metroplex traffic flow is more efficiently managed through arrival/departure and surface scheduling 
automation, integrated with all available constraint information, including weather impacts, 
optimizing traffic throughput by eliminating potential gaps in unused capacity, thereby increasing 
regional/metroplex capacity. 

Data communications is a key element of super-density operations, allowing the Air Navigation 
Service Provider (ANSP) to maximize access for all traffic, while adhering to the principle of giving 
advantage to those aircraft with advanced capabilities. 

01 104206 — Full Surface Traffic Management with Conformance Monitoring: Efficiency and 
safety of surface traffic management is increased, with corresponding reduction in environmental 
impacts, through the use of improved surveillance, automation, on-board displays, and data link of 
taxi instructions. 

Equipped aircraft and ground vehicles provide surface traffic information in real-time to all 
parties of interest. 

01 104208 — Enhanced Departure Flow Operations: Enhancements to surface traffic 
management incorporate taxi instructions, surface movement information, and aircraft wake category 
to enhance departure flow operations. Clearances are developed, delivered, monitored and provided in 
graphical or textual format that is used by the flight deck display to support taxi, takeoff and 
departure flows in all conditions. At high-density aiiports clearances and amendments, requests, NAS 
status, airport flows, weather information, and surface movement instructions are issued via data 
communications. 

Surface decision support and management systems use ground and airborne surveillance and a 
scheduling and sequencing system to develop and maintain schedules of departing aircraft within a 
defined time horizon. Information is sent to participating aircraft and the air navigation service 
provider via data communications or voice and adjustments are made to push back times, taxi 
instructions, etc. to maintain schedules. 

01 104209 — Initial Surface Traffic Management: Departures are sequenced and staged to 
maintain throughput. ANSP automation uses departure -scheduling tools to flow surface traffic at 
high-density airports. Automation provides surface sequencing and staging lists for departures and 
average departure delay (current and predicted). 

ANSP automated decision support tools integrate surveillance data. This includes weather data, 
departure queues, aircraft flight plan information, runway configuration, expected departure times, 
and gate assignments. 

Improve collaborative air traffic management (excerpts from Ref. 34) 

01 101102 — Provide Full Flight Plan Constraint Evaluation with Feedback: Timely and accurate 
national airspace system (NAS) information enables users to plan and fly routings that meet their 
objectives. Constraint information that impacts the proposed route of flight is incorporated into air 
navigation service provider (ANSP) automation, and is available to users. Examples of constraint 
information include special use airspace status, S1GMETS [data link significant meteorological 
information], infrastructure outages, and significant congestion events. 

01 103305 — On-Demand NAS Information: National Airspace System (NAS) and aeronautical 
information will be available to users on demand. NAS and aeronautical information is consistent 
across applications and locations, and available to authorized subscribers and equipped aircraft. 
Proprietary and security sensitive information is not shared with unauthorized agencies/individuals. 
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01 105207 — Full Collaborative Decision Making: Timely, effective, and informed decision- 
making based on shared situational awareness is achieved through advanced communication and 
information sharing systems. 

Stakeholder decisions are supported through access to an information exchange environment and 
a transformed collaborative decision making process that allows wide access to information by all 
parties (whether airborne or on the ground), while recognizing privacy and security constraints. 
Decision-makers request information when needed, publish information as appropriate, and use 
subscription services to automatically receive desired information through the net-centric 
infrastructure service. 

Reduce weather impact (excerpts from Ref 34) 

103119 — Initial Integration of Weather Information into NAS Automation and Decision Making: 
Advances in weather information content and dissemination provide users and/or their decision 
support with the ability to identify specific weather impacts on operations (e.g., trajectory 
management and impacts on specific airframes or arrival/departure planning) to ensure continued safe 
and efficient flight. Users will be able to retrieve (and subscribe to automatic updates of) weather 
information to support assessment of flight-specific thresholds that indicate replanning actions are 
needed. In particular, the 4-D Weather Data Cube (and later The 4-D Weather Single Authoritative 
Source (4-D Wx SAS)) will support enhanced volumetric extractions, by timeframe of interest, of 
weather information by NAS users to quickly filter the enhanced weather content to the region of 
interest for impact analysis. This will streamline the process by which the user — with or without 
decision support ATM tools — conducts system-wide risk management in planning for both individual 
flight trajectories and flows. 

103121 — Full Improved Weather Information and Dissemination: This improvement provides the 
full capability that supports the NextGen concept of operations to assimilate digital weather 
information into decision-making for all areas of operations. 

103123 — Full Integration of Weather Information into NAS Automation and Decision Making: 
Further advances in weather information content and dissemination and a NAS-wide increase in the 
direct integration of weather into decision support tools will enable users and service providers to 
more precisely identify specific weather impacts on operations (e.g., trajectory management and 
impacts on specific airframes or arrival/dcparturc planning) to ensure continued safe and efficient 
flight. 

3.4.1.2 AeroMACS Operational Environment for Next Generation Air Transportation System 

Along with the As-Is SV-2 of the NAS developed by the FAA Air Traffic Organization (ATO) 
planning organization, such as shown in Figure 8, were a series of separate “to-be” views for 2025. 

Figure 15 presents an SV-2 2025 rollup data flow view for the proposed NAS. The figure was annotated 
with labels and dashed red boxes to highlight the five NAS information flow areas that may be enabled by 
AeroMACS: 

• Surveillance 

• Weather 

• Flight information 

• Command and control 

• Aeronautical information 
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Acronyms are defined in Appendix A. 



3.4.2 Proposed System Description: AeroMACS 

As noted earlier, the FCS technology assessment recommended a system based on the IEEE 802.16 
standard and its extension, IEEE 802.16e-2005 (Refs. 6 and 19) implemented at the aeronautical C-band 
as the preferred technology to implement a future airport surface communications system (i.e., 
AeroMACS). This standard and its extension were later incorporated into the IEEE 802.16-2009 
standard, which will be referenced as appropriate. The waveforms described in IEEE 802.16-2009 
standard are very flexible and scalable to handle a wide range of communication services. The Worldwide 
Interoperability Microwave Access (WiMAX) Forum, an industry consortium that promotes the use of 
wideband wireless systems based on a carefully selected and agreed upon subset of the IEEE 802.16 
standards, has developed several profile applications that will be supported by device manufacturers. A 
new standards profile for airport applications is currently being developed within an RTCA special 
committee (SC-223) to operate in the C-band (5091 to 5150 MHz) and make use of the scaling properties 
inherent in IEEE 802.16-2009 standard. The updated version of 802.16 and 802. 16e, IEEE 802.16-2009, 
provides the basis of ongoing the profile selection. The IEEE 802.16-2009 standard defines the waveform 
capabilities needed for various uses. It has considerable flexibility at the physical and Media Access 
Control (MAC) layers that will lead to a number of tradeoffs in adapting this type of waveform to the 
needs of an AeroMACS. Some of the tradeoffs to be considered follow: 

• Bandwidth (capacity) versus number of base stations (BSs) 

• Allocation methodology for mapping channel assignments 

• Number of power control levels 

• Allocation of capacity for voice circuits 

The proposed AeroMACS could provide supplemental means for the ATC communications required by 
the operating rules (e.g., VHF voice communications) in continental airspace (albeit on the airport surface) 
and will adhere to the data link characteristics noted in the “Safety and Performance Requirements Standard 
for Air Traffic Data Link Services in Continental Airspace (Continental SPR Standard)” (Ref. 7). 

3.4.3 AeroMACS Frequency and Technology: Environment, Requirements, and Limitations 

To ensure traceability, presented here are the following observations regarding airport surface 
communications and the suitability of the aeronautical C-band resulted from the “Future Aeronautical 
Communication Infrastructure Technology Investigation” (Ref. 28): 

• The propagation conditions to some extent determine which band is able to support which types 
of volume. The airport surface is best served by short range systems operating in the C-band 
because of the attenuation conditions at this frequency. 

• There is capacity that is not utilized in the aeronautical C-band (5000 to 5010 MHz, 5010 to 
5030 MHz, and/or 5091 to 5150 MHz). Because of severe path-loss problems, this band is most 
applicable to the airport surface where the distances are relatively short. Some concepts for 
surface management communications require substantially higher data rates than are needed in 
other airspace domains and may warrant a specific technology solution. 

• For the aeronautical C-band (5000 to 5010 MHz, 5010 to 5030 MHz, and/or 5091 to 5150 MHz), 
IEEE 802.16-2009 is extremely well matched to the aeronautical surface in terms of capability 
and performance. 

- This technology is designed to work in this band and initial IEEE 802.16-2009 performance 
evaluations in the modeled aeronautical microwave-landing-system (MLS) band channel 
show favorable results 

- Private service providers have shown interest in the IEEE 802.xx family of wireless protocols 
(favorable business case that may be driven by factors beyond ATS and AOC communica- 
tions, and may involve private service providers, including airport authorities) 
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These conclusions help to drive the AeroMACS ConUse and system requirements presented in this 
document. 

3.4.4 User Impact 

Users of the system will include service providers and airspace users (on the airport surface) of A/G 
and G/G communications: 

• Safety and regularity of flight — addressed by air traffic controllers and NAS specialists on the 
ground and flight crews in aircraft at the airport 

• Commercial data transfer related to airline operations and provisions of services to passengers 

The introduction of AeroMACS is expected to increase communications system capacity, thus 
allowing the addition of new services and expanding the user base. Figure 16 illustrates the effect of the 
new system on the user base. 

It should be noted that the relationship between the capacity demand and changes in the user base can 
be viewed as a repeating cycle of events. The proposed introduction of an AeroMACS will increase the 
overall capacity of the system and open up opportunities for addition of data services not provided under 
Data Comm. Many of those, most notably services associated with the Airborne SWIM Program, would 
provide for wider system use. Not only more users would be expected to take advantage of the new data 
communications capabilities, the types of users allowed to participate would increase as well. 

As more data services are introduced and become part of day-to-day operations, the demand for 
additional services, and therefore capacity, is expected to grow. The availability of a new frequency band, 
such as C-band, in addition to the VHF frequencies supporting the existing voice and data communica- 
tions services, will alleviate long-term capacity problems. 


Increased 

system 

capacity 



Introduction 
of new 
services 



Need for 
more data 
services 



Wider user 
base 


Change in 
type and 
number of 
users 



Figure 16. — Communication system capacity 
demand and user base changes. 

The expanded use of advanced technologies in general and of AeroMACS in particular, along with 
increased capacity, is expected to improve aviation safety and enhance operational efficiency for NAS 
users. The continued migration from a NAS based on a ground infrastructure and voice communication to 
a system that encompasses both ground and airborne components and utilizes the exchange of digital data 
as the primary type of communication, will “support the human in doing what they do best — choosing 
alternatives and making decisions, while the technology accomplishes what it can do best — the 
acquisition, compilation, evaluation and exchange of information” (Ref. 4). 
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NextGen communications systems will enable users to play a more active role in each of the NAS 
service areas: 

• NAS management (strategic flow and resource management): SWIM capability will enable 
stakeholders’ access to relevant information. Users will become key participants in the planning 
of traffic flow management and will utilize a comprehensive information exchange process to 
improve flight operations planning according to capacity and traffic conditions to minimize 
congestion and delays. 

• Flight planning and emergency alerting services: Users will have interactive flight planning 
capabilities with an immediate access to real-time data. User-preferred routing will become 
available to properly equipped aircraft for both domestic and international flights. 

• Surface operations: Increased data-exchange capabilities will provide more users at more airports 
with flight clearances, airport information, positions of other aircraft, taxi routes, and weather 
conditions (current, forecast, and hazardous). Users will have improved real-time planning with 
continuous update of the flight profile. 

3.4.5 Operational Policies and Constraints 

Operational aspects of aeronautical communications are changing with an increased emphasis on 
safety and cost reduction achieved via increased automation and efficiency, fewer delays, and other 
improvements. 

General issues such as cost, spectrum availability, technology choice, and standards development, as 
well as the logistics of system rollout will all influence operational policies and constraints. 

The NextGen ConOps details operational policy issues that would affect the NextGen system 
(Ref. 37). To support the proposed AeroMACS development and implementation, policies might need to 
be developed and/or revised in the following areas: 

• International and domestic regulations 

• Safety management standards 

• Processes to streamline certification and reduce costs of aircraft and ground equipment 

• Privacy and liability legal concerns related to information sharing, 

• Communications priority and congestion relief (e.g., market-driven versus aircraft type) 

• Government role versus private sector role 

• Financing and maintenance responsibilities 

3.5 AeroMACS ConUse 

3.5.1 RTCA National Airspace System Concepts of Operation Guidance 

As noted in Section 2.0, the definitions of the AeroMACS ConUse were based on guidance and 
information provided by several higher order ConOps. A key NAS ConOps source driving the 
AeroMACS ConUse is RTCA’s NAS ConOps (Ref. 4). Appendix B presents a comprehensive listing 
derived from Reference 1 3 of future communications concepts applicable to airport surface operations to 
enable the transfer of the following NAS information types: 

• Surveillance 

• Weather 

• Flight planning 

• Aeronautical information 

• Resource management 
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3.5.2 Data Comm Operational Scenarios 

Operational scenarios can illustrate how proposed system capabilities could be used in an operational 
environment. The scenarios can demonstrate how the services offered by the new communications system 
could help to 

• Minimize operational errors, including those resulting from misunderstood instructions and read- 

back errors 

• Improve efficiency 

• Provide further automation of traffic control 

• Enable more decisions to be made off the ground 

The Data Comm FPR (Ref. 5) lists operational scenarios envisioned to be enabled by the data 
communications system. In general, these scenarios would also be applicable to an AeroMACS 
implementation, especially those presented for Segment 2 and beyond, during which Data Comm VDL 
Mode 2 operational capabilities could be augmented by AeroMACS. Operational scenarios from 
Segments 2 and 3 of Data Comm that are applicable to the airport surface environment follow (Ref. 5). 

• Departure Airport (Tower) Scenarios 

- (S2,3) Proposed routes including standard routing through traditional airspace, and 4-D 
trajectory based routing for transit through High Performance Airspace are developed and 
loaded into the flight management system via A/G data communications for aircrew review. 

- (S2,3) At the request of the flight crew, ATM-related operational data for the flight (e.g., 
departure sequence, collaborative decision making agreements, and slot-time allocations) are 
relayed by data communications to the flight crew in preparation for departure. 

- (S2,3) After issuance of the departure clearance, the automation system generates a request 
via data communications to the aircraft automation to report its active route. This information 
is compared with the departure clearance to verify consistency. 

- (S2,3) Once the flight crew compares and validates the departure clearance against the filed 
flight plan, the flight crew requests a taxi route instruction using data communications. The 
assigned controller reviews the taxi route instruction suggested by the automation for the 
aircraft, and upon approval, sends the taxi route instruction via data communications. Taxi 
revisions via data communications are now provided not only to reroute aircraft, but also to 
reorder aircraft. 

- (S2,3) Enhanced capabilities and increased access to surface data and flight status provide 
traffic management automation with information about the flight’s location, taxi sequence, 
and the departure queues. As a result, the TFM [traffic flow management] automation 
provides departure clearance revisions at an operationally appropriate amount of time in 
advance of the departure. 

- (S2,3) Once the aircraft has been cleared for takeoff via voice, data communications manages 
the data communications eligibility transfer to the TRACON position and surface ATC data 
communications cease. 

- (S3) In advance of a planned departure, users now file 4D trajectory-based flight plans for 
operations in HPA [high-performance airspace]. Users and air traffic service providers 
[ATSPs] collaborative ly negotiate 4-D trajectory agreements from takeoff to approach, based 
on user requests and anticipated constraints. This agreement is embedded in the departure 
clearance. The final point in the clearance also includes the required time constraint for the 
arrival fix. 
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Arrival Airport (Tower) Scenarios 


- (S2,3) The tower ground controller clears the flight crew to taxi via voice or data 
communications depending upon the dynamics of the situation and monitors the traffic 
situation as they maneuver the aircraft to the arrival gate. 

- (S3) After the aircraft lands, the tower runway controller confirms the previously provided 
runway exit and directs the flight crew to contact the ground controller. 

3.5.3 Proposed Services for AeroMACS 

Figure 17 and Table 5 show the potential AeroMACS services in three categories: air traffic, airline, 
and airport. 



Figure 17. — Potential AeroMACS service categories in the United States (Ref. 8). 


TABLE 5.— AEROMACS SERVICE EXAMPLES AND PROVISION OPTIONS (REF. 8) 


Air Traffic Services 

Service Examples 

• Air traffic control commands beyond Data Comm Segment 3 

• Surface communications, navigation, and surveillance (CNS) fixed assets 

Provision Options 

• Government-owned (licensed)/Government-operated (GO/GO) 

• Government-owned (licensed)/Commercially-operated (GO/CO) 

• Non-competed service extension via FAA Telecommunications Infrastructure (FTI) 

• Open commercial competition by FAA 

Airline services 

Service examples 

• Airline Operational Control (AOC) 

• Airline Administrative Communications (AAC) 

• Advisory information 

• System Wide Information Management (SWIM) 

• Aeronautical Information Management (AIM) 

• Meteorological (MET) data services 

Provision options 

• Commercially-owned (licensed)/Commercially-operated (CO/CO) 

• Non-competed service extension via exiting AOC service providers 

• Airline service provision internally 

• Open commercial competition by airlines 
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TABLE 5.— AEROMACS SERVICE EXAMPLES AND PROVISION OPTIONS (REF. 8) 


Airport operator/port authority services 

Service examples 

• Security video 

• Routine and emergency operations 

• Dc-icing/snow removal 

Provision options 

• Local Government-owned (licensed)/Commercially-operated (GO/CO) 

• Commercially-owned (licensed)/Commercially-operated (CO/CO) 

• Open commercial competition by Operator/Port Authority 


3.5.3. 1 Air Traffic Services 

Reference 9 classifies all of the COCR ATS data services as safety critical. It further identifies 
services that are not planned to be implemented by Data Comm through Segment 3 and identifies them as 
possible candidates for implementation via C-band and/or L-band. It must be stressed that both C-band 
and L-band systems are being developed for the future communications infrastructure to accommodate 
the safety and regularity of flight services. These are designed to operate over a protected spectrum for 
aviation, so any COCR ATS could be allowed to be implemented via one or the other of these link s (as 
appropriate). 

As described earlier, this document focuses on the COCR ATS data services that are not expected to 
be provided by Data Comm through Segment 2, which are proposed as candidates for AeroMACS. 


• Flight information services 

- Data link operational terminal information service (D-OTIS) Data link runway visual range 
(D-RVR) 

- Data link surface information and guidance (D-SIG) 

- Data link significant meteorological information (D-SIGMET) 

• Flight position, flight intent, and flight preferences services 

- Pilot preferences downlink (PPD) 

- Flight plan consistency (FLIPCY) 

- Wake service (WAKE) 

• Emergency information service 

- Urgent contact (URCO) — if in conjunction with other more routine services 

Additional data services that may be provided via AeroMACS may be identified as NextGen and 
Single European Sky ATM Research (SESAR) progress. 

3.5.3.2 AOC Services 

COCR AOC Data Services Table 6 lists the AOC data services noted in the COCR v.2.0 (Ref. 1 1). 
Position Report (POSRPT) is not included in the table because it is not provided on airport surface. Some 
of the services listed, for example Software Loading (SWLOAD), would be provided the ground, while 
others may be applicable to wheels on- and off-the-ground scenarios with AeroMACS enabling these 
services on the airport surface only. 
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TABLE 6. — COCR V.2.0 AOC DATA SERVICES 


Service 

Acronym 

AOC Data Link Logon 

AOC DLL 

Cabin Log Book Transfer 

CABINLOG 

Engine Performance Reports 

ENGINE 

Flight Log Transfer 

FLTLOG 

Flight Plan Data 

FLTPLAN 

Flight Status 

FLTSTAT 

Free Text 

FREETXT 

Fuel Status 

FUEL 

Gate and Connecting Flight Status 

GATES 

Load Sheet Request/Transfer 

LOADSHT 

Maintenance Problem Resolution 

MAINTPR 

Real Time Maintenance Information 

MAINTRT 

Notice to Airmen 

NOTAM 

Out-Off-On-In 

OOOI 

Software Loading 

SWLOAD 

Technical Log Book Update 

TECHLOG 

Update Electronic Library 

UPLIB 

Graphical Weather Information 

WXGRAPH 

Real-time Weather Reports for Met Office 

WXRT 

Textual Weather Reports 

WXTEXT 


Services with larger bandwidth requirements, for example WXGRAPH, UPLIB, SWLOAD, may be 
more suitable to provide via AeroMACS while services involving smaller traffic volumes may be more 
appropriate for a VDL Mode 2 system. 


3.5.3.2.1 Additional AOC Services Not Covered by the COCR 

The New AOC/AAC Services document (Ref. 12) 10 provided by the European SANDRA Program 
specifies additional services not mentioned by the COCR but recommended based on industry feedback 
during data link standardization activities. 

Although the services are already implemented in new aircraft, they are highly customizable. 

As noted in the document, the following list does not claim to be exhaustive, and feedback is still needed 
from Airbus and major airlines. 


10 The source document used (New AOC/AAC Services. SANDRA. 22 March 2010. Draft) is a work in progress. As 
such, the list of services presented here may change. 
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TABLE 7.— PROPOSED NEW AOC/AAC SERVICES 


Service 

Acronym 

Allowed on Sandra 

Electronic Flight folder exchange with ground of flight data for cockpit 

EFFuplink 

X 

crew collected on ground. Format defined by ARINC 633 

EFFdownlink 


Exchange with ground of aircraft Configuration data. 

CONF 

X 

Exchanges of performance data with ground (computation on ground). 
Note: this service may be specific to some airline operators only, as the 
technical trend is rather to integrate these functions in avionics, as for 
business jets for example, instead of using data links. 

PERF 

X 

Flight data records transmitted on ground. 

VQAR 

WiMAX only: proposal is 
to allow it. This system has 
the ability, if transmission 
was not complete when 
aircraft departs, to resume 
transmission at the 
following airport. 

Air to ground cabin video streaming for security/surveillance (potential 

CVM 

X 

future use case — to be discussed) 


This service is TBC 

Real time of summary transmission of failures/monitored CABIN/IFE 
parameters 

CabMAINTTRT 

X 

Transmission of telemedicine data to ground (sick passenger) 

TELEMED 

X 

Ordering and provisioning of fuel from cockpit when on ground. 

REFUEL 

X 

Dc-icing service ordering and management from cockpit when on ground 

DEICING 

X 


CVM and VQAR involve transmission of large amounts of data (up to several tens of Mbytes). The 
remaining services listed above are similar to the AOC services defined in COCR v.2.0 (Ref. 1 1) in 
terms of the required message sizes, data rates and phase of flight usage. 

The AOC services in Table 7 may be mapped to the Flight Regularity category (Ref. 38) and may be 
transported over the AM(R)S link. 

As noted earlier, services with large bandwidth requirements may be more suitable to provide via FC1 
(e.g., L-DACS and AeroMACS) while services involving smaller traffic volumes may be more 
appropriate for a VDL-2 based system. 

As part of the follow-on AeroMACS development work, we recommend following the activities of 
the Airlines Electronic Engineering Committee (AEEC) Data Link Systems subcommittee that is 
developing a specification for the Media Independent Aircraft Messaging (MIAM). M1AM is intended to 
support the transport of very large messages over the ACARS (and eventually other) networks. While the 
current EUROCONROL effort focuses largely on applying MIAM to the VDL Mode2 networks 
(Ref. 39), it should also be evaluated in respect to AeroMACS. 


3.5.3.2.2 Airborne System Wide Information Management (SWIM) Suitable Services 

Introduction of AeroMACS would support transitioning from Aeronautical Information Services 
(A1S) to Aeronautical Information Management (AIM) (Ref. 12) notes a data-centric nature of AIM as 
opposed to the product-centric nature of A1S and emphasizes the need for a robust communication 
network to enable digital communication services and support the increasing bandwidth demands. 

SWIM, an FAA technology program designed to facilitate the sharing of ATM system information 
(airport operational status, weather information, flight data, status of special-use airspace, and NAS 
restrictions), can be implemented via G/G, A/G, and air-to-air (A/A) communications infrastructure 
components. Each of these components would enable efficient data exchange between authorized users 
in the respective domain. An AeroMACS could provide means for the A/G data transfer among fixed and 
mobile users on the airport surface. 
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An implementation of AeroMACS would facilitate meeting the primary objective of the SWIM 
Program: that is, to improve the FAA’s ability to manage the efficient flow of information through the 
NAS. When used to enable Airborne SWIM capabilities, an AeroMACS could be designed to ensure that 
its use provides the following desired SWIM features: 

• Reduced costs for NAS users to acquire NAS data and exchange information 

• Increased shared situational awareness among the NAS user community 

• Ensure FAA-compliant secure data exchange among the NAS user community 

Figure 18 shows how SWIM (with the communication links with aircraft and other mobile users on 
the airport surface potentially provided via AeroMACS) fits in the overall FAA Information exchange 
model. 
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Figure 18. — Information exchange model (Ref. 40). 

Although it is anticipated that some advisory Airborne SWIM (also referred to as Aircraft Access to 
SWIM or AAtS) services could be provided over the commercial (i.e., unprotected (non-AM(R)S)) 
spectrum — as shown in the figure — it is likely that in the future other Airborne SWIM services, such as 
graphical weather subscription and aeronautical information updates could go beyond advisory use and 
directly impact safety and/or regularity of flight. As such, their service provision would have to make use 
of protected spectrum to support safety and/or regularity of flight. 1 1 This class of potential AAtS services 
would be suitable targets for an AeroMACS implementation. 

As part of SWIM, AeroMACS would enable the exchange of information between diverse users 
adopting a service-oriented architecture. Services would be offered from individual providers as well as 
centralized providers. 


n For example, current aeronautical (airline) operational control (AOC) communications is conducted over the 
AM(R)S spectrum to support regularity-of-flight operations rather than safety-of-flight operations. 
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Figure 19 shows the A/G and G/G SWIM elements. It depicts Airborne SWIM (potentially provided 
over AeroMACS whenever aircraft wheels are in contact with the surface) as a facilitator of NAS data 
exchange, such as surveillance, flight, aeronautical, meteorological, air traffic flow and capacity 
management (ATFCM) scenario, and demand and capacity data. 
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Figure 19. — Air-to-ground data link management and aircraft participation in System Wide Information Management 
(SWIM) (slightly modified from Ref. 41). Copyright Thales Air Systems; used with permission. Acronyms are 
defined in Appendix A. 


These mostly weather advisory and aeronautical information services that could be provisioned via 
AeroMACS include 


• Aviation Digital Data Service (ADDS) 

• AWOS Data Acquisition Service (ADAS) 

• Expanded Terminal and Tower Data Service 

• General Information Message Distribution Service 

• Information Display System (IDS) Data Service 

• NextGen Network Enabled Weather (NNEW) service 12 

• NOT AM distribution service 

• TMA flight data service 

• Weather and Radar Processor (WARP)/Weather Information Network Server (WINS) Next 
Generation Radar (NEXRAD) service 


12 

It is possible that the information provided through the NNEW service could range from the advisory for routine 
forecasts through safety critical information for certain hazardous weather warning messages, which might limit the 
extent to which this might be provided over commercial links. This requires further investigation. 
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Reference 42 provides ATM-weather integration plan and emphasizes the need for an efficient flow 
of weather information and its translation into constraints to enhance decisions. 

Several Ols identified in Section 3.4. 1.1 as those potentially enabled by AeroMACS are noted as part 
of the NextGen solution set-oriented weather integration analysis. Ols 104117, 102406, 104207, 104208, 
104209, as well as 101102 and 103305 would require mid-term weather-related capability with the 01 
104117- Improved Management of Arrival/Surface/Departure Flow Operations - leveraging “advanced 
communications and automation technologies as the primary means of accomplishing its goals” (Ref. 43). 
The proposed AeroMACS offers communications links to fulfill the demand for such communication 
technology. 

Under the 01 101102 — Provide Full Flight Plan Constraint Evaluation with Feedback — a user would 
be able to adjust the flight plan based on available information and re-file as additional information is 
received. Updated information would be provided to filers if conditions along trajectory change with a 
user being able to submit alternative flight plans if needed. After filing a flight plan and up to departure, 
weather and nonweather constraints that impact the plan as well as FAA mitigation strategies would be 
provided to the user. 

[The] evaluation capability will provide the user with feedback that is based on consistent information 
to that of the ANSP, thereby increasing common situational awareness. The feedback will include 
current and predicted information for a flight along its complete flight path (i.e., full route) 
throughout the flight’s life cycle. The feedback will include weather information, probabilistic 
information, TMls (including delay information), airspace information (e.g., Eligh Performance 
Airspace [E1PA]/Mixed Performance Airspace [MPA], RNAV routes), required aircraft performance 
characteristics (e.g., RNP, RNAV requirements), active routes, restrictions (e.g., Letters of 
Agreement (LOAs), SOPs, SAA, terminal status information (e.g., airport conditions, runway 
closures, wind, arrival rates, RVR, airport (current and planned) configurations, surface information, 
and other NAS status information and changes along the path of the evaluated route or filed route. In 
addition, the nature (e.g., fully restricted or conditional access), the time, and the impact (e.g., 
distance, delay) associated with any restriction or constraint will be provided. It is expected that the 
evaluation feedback will evolve as changes in airspace, and new information systems become 
integrated and available (Ref. 43). 

Users with a different level of flight planning capabilities would have access to varying levels of 
information. AeroMACS could provide communications links to enable these services. 

Figure 20 illustrates full flight plan constraint evaluation and feedback OI in the context of SWIM 
showing interactions with other Ols. 
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Figure 20 . — Full flight plan constraint evaluation and feedback 01 in the context of SWIM showing 
interactions with other Ols mid-term operational scenario (Ref. 42). 


Figure 21 illustrates the introduction of SWIM services over time. Implementation of the proposed 
AeroMACS could overlap with SWIM Segments 3 and 4 when Airborne SWIM is introduced. 
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Figure 21. — System Wide Information Management (SWIM) execution by segments (Ref. 37). 
Acronyms are defined in Appendix A. 
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3.5.3.3 


Unmanned Aircraft Systems (UAS)-Related Services 

Services specific to the operation of UAS in the NAS and potentially suitable for implementation via 
AeroMACS whenever the unmanned aircraft (UA) is on the ground would include the following: 

• Pilot/UA control links, including telecommand and telemetry 

• Pilot/UA NavAids data exchanges 

• Relaying ATC voice messages to and from UA pilots 

• Relaying ATS data messages to and from UA pilots 

• UA-to-pilot downlinking of nonpayload target-track data 

• UA-to-pilot downlinking of data from UA-bome weather radars 

• UA-to-pilot downlinking of safety-related video data from UA to pilots 

• UA-to-pilot downlinking of safety-related sense-and-avoid automated decision making from UA 
to pilots 

A notional system architecture consisting of three segments and the associated internal and external 
interfaces are shown in Figure 22. The detailed description as well as notional diagrams of each segment 
can be found in RTCA DO-304 (Ref. 44) and are not replicated here. 



Figure 22. — Unmanned aircraft system (UAS) notional architecture 
(Ref. 42). Acronyms are defined in Appendix A. 


Communication in either of the segments in Figure 22 can be provided via AeroMACS. It should be 
noted, however, that because of current spectrum requirements, AeroMACS would only be used when the 
UA has “wheels on the ground.” Other links (i.e., VHF, L-band, or others) would provide en-route 
communications services. 

3. 5.3.4 RTCA SC-223 User Services and Applications Survey Working Group 

The RTCA SC-223 has formed a User Services and Applications Survey (USAS) Working Group 
(WG) to collect information from various AeroMACS stakeholders. The group compiled the data for the 
existing and future applications in the following functional domains: 
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• Air Traffic Control/Air Traffic Management (ATC/ATM) 

• Aeronautical Information (AIM) 

• Airlines/Cargo Operations (Airline/Cargo Ops) 

• Airport Operation (Airp Ops) 

• Airport Infrastructure (Airp Infr) 

SESAR Project P 15.2.7 input was incorporated noting the new AOC services proposed by 
SANDRA. 

The second level of information collection included technical parameters and potential performance 
requirements for each of the application in various functional domains. 

At the time of this report, the list of applications compiled by the group was not validated for 
AM(R)S use or duplication with the FAA Data Comm program. Rather, it attempts to present a superset 
of communication services that can potentially be enabled by AeroMACS. 

Appendix E presents WG’s projection of the most likely applications to be supported by AeroMACS. 
It should be noted that at the time of this report the WG is still updating the spreadsheet. The version 
presented in Appendix E is a work-in-progress document with the estimated completion time 
December 31, 2010. 

3.5.4 Next Generation Air Transportation System Communications Operational Concepts 

Figure 23 shows a typical flight profile and the ATS functions supporting users in each domain. 



Figure 23. — Typical National Airspace System (NAS) flight profile and air traffic services (ATS) functions (Ref. 5). 

Table 8 lists the operational scenarios and concepts envisioned for the midterm of the NextGen 
airport surface flight phase shown in Figure 23. Although most, if not all, of these concepts are currently 
envisioned for Data Comm, these are technology-independent and, thus, equally valid for an AeroMACS 
implementation. 


TABLE 8.— NEXT GENERATION AIR TRANSPORTATION SYSTEM (NEXTGEN) MIDTERM OPERATIONAL 

CONCEPTS FOR THE AIRPORT SURFACE 


Phase of flight 

NextGen midterm communications operational concept (from Ref. 10) 

Flight planning 

Access to flight planning information will be available to authorized users via a secure network 
and will include a publish/subscribe capability so that users can receive automatic updates when 
conditions change along the proposed flight path. 

Push back, taxi, and 
departure 

As the time for the flight approaches, the final flight path agreement will be delivered as a data 
message to pilots who access the agreement before beginning the flight. 
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3.5.5 Potential AeroMACS Operational Services Derived from the Communications Operating 
Concept and Requirements 

Operational concepts also can be defined according to the different geographic flight domains. 
Table 9 illustrates the potential operational services suitable for implementation via AeroMACS for the 
airport surface based on the COCR services previously identified as potential applications (Ref. 9). 

TABLE 9.— USE OF THE PROPOSED AeroMACS IN THE AIRPORT FLIGHT DOMAIN 


[Acronyms are defined in Appendix A.] 


Operational services 

Airport domain (APT) phases 


Predeparture 
airport domain 

Departure taxi 
airport domain 

Arrival airport 
domain 

Anival taxi 
airport domain 

Flight information services 

D-OTIS a 

D-RVR' 1 

D-SIG 

D-SIGMET 

D-OTIS a 

D-RVR 11 

D-SIG 

D-SIGMET 

D-OTIS a 

D-RVR 11 

D-SIG a 

D-RVR a 

D-SIG a 

Flight position, flight intent, and flight 
preferences services 

PPD 

FLIPCY 

WAKE 

PPD 

FLIPCY 

WAKE 

PPD 

FLIPCY 

WAKE 

PPD 

FLIPCY 

WAKE 

Emergency infonnation service 





Services suitable for Airborne SWIM 
(generally weather advisory and 
aeronautical information services) 

ADDS, ADAS, Expanded Terminal and Tower Data Service, General Information 
(GI) Message Distribution Service, IDS Data Service, NNEW service, 15 NOTAM 
distribution service, TMA Flight Data Service, WARP /WINS NEXRAD service 


“At the time of this report D-OTIS and D-RVR are listed as part of the RTCA SC-214 scope. As noted throughout this report, 
the services are considered candidates for AeroMACS if not implemented by the Data Comm program. 
b It is possible that the infonnation provided through the NNEW service could range from advisories for routine forecasts 
though safety-critical transmission of certain hazardous weather warning messages, which might limit the extent to which this 
service could be provided over commercial links. This requires furtherer investigation. 


Examples of operational messages that could be transmitted over the proposed AeroMACS data link 
in support of the services for the airport surface flight domain are presented in Table 10. The messages 
are grouped according to the infonnation type, as defined by the function identifications (IDs) in 
Appendix C. 


TABLE 10.— EXAMPLE AEROMACS DATA LINK MESSAGES 


Infonnation type (including 
conesponding function ID) 

Message examples 

Transceive air traffic service 
(ATS) to on-ground aircraft 
message 
C. 1.1. 1.2 

Contract requesting data 
Contract acknowledgements 

Operational tenninal information service (OTIS) reports, addressed or broadcast 
communications 

Significant meteorological infonnation (SIGMET) reports, addressed or broadcast 
communications, event basis only 

Airport data to be displayed on board (Data Link Surface Information and Guidance, 
D-SIG) 

Runway visual range (RVR) infonnation, addressed or broadcast communications 
Urgent contact message (URCO), addressed and/or broadcast communications 
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TABLE 10.— EXAMPLE AEROMACS DATA LINK MESSAGES 


Information type (including 
corresponding function ID) 

Message examples 

Transceive on-ground aircraft to 
ATS message 
C.l. 1.2.2 

Requests (i.e., demand, periodic, or event contract) for reports 
Contract acknowledgements 

Current and periodic position (flight plan consistency, (FLIPCY)), addressed 
communications 

Meteorological data (FLIPCY), addressed communications 
Ground speed (FLIPCY), addressed communications 

Indicated heading, indicated air speed or match, vertical rate, selected level, and wind 
vector (system access parameters), addressed communications 

Broadcast of aircraft wake turbulence (WAKE) characteristics (e.g., aircraft type, weight, 
and flap and speed settings) 

Flight limitations (e.g., maximum acceptable flight level) (pilot preferences downlink, 
PPD), addressed communications 

Pilot flight preferences (PPD), addressed communications 

Flight plan modification requests (e.g., desired route or speed limitations) (PPD), 

addressed communications 

URCO, addressed and/or broadcast communications 
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4.0 AeroMACS network requirements 

4.1 AeroMACS Functional Requirements Development Process 

Section 2.0 presented an overview of the ConUse and system requirements development process used 
for this task. As stated in Section 2.0, a middle-out approach was adopted to identify the high-level 
requirements applicable to AeroMACS. In this approach, the top-down functional requirements were 
derived from the ConUse and the associated functional capabilities. In parallel with that process, a 
bottom-up assessment of existing requirements in relevant documents such as the NAS SR- 1000 
(Ref. 13), the COCR (Ref. 1 1), and Data Comm performance requirements and their applicability to the 
current needs for AeroMACS was performed. Thus, the top-down approach employs the classic “clean- 
sheet” system engineering process, and the bottom-up approach addresses how AeroMACS fits into the 
existing environment. 

Volume 11 of this report presents further recommendations of the AeroMACS requirements from the 
tests and references the documents developed by the RTCS SC-223. 

4.1.1 AeroMACS Functional System Requirements — Top-Down Approach 

This section presents a top-down determination of functional requirements through ( 1 ) a functional 
analysis for generic aeronautical communications systems based on prior work and (2) a functional 
analysis based on the ConUse defined in Section 3.0. 

4. 1 . 1 . 1 Prior Functional Analysis Applicable to AeroMACS 

A functional architecture can be interpreted as a hierarchical arrangement of functions and interfaces 
that represents the complete system from a performance and behavioral perspective (Ref. 2). For its top- 
down functional analysis, this report leverages prior functional analysis work performed to characterize 
generic aeronautical A/G, G/G, and A/A communications systems: the “National Airspace System 
Communications System Safety Hazard Analysis and Security Threat Analysis” (Ref. 25). Figure 24 
depicts the hierarchy at the highest level. Appendix C presents a more complete hierarchical 
decomposition of functions as diagrams and in an outline format derived from this reference document, 
but modified as appropriate for AeroMACS (e.g., A/A functions are deleted). 



Figure 24. — High-level hierarchy of C-band communications system. Acronyms are defined in Appendix A. 
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4. 1.1. 2 AeroMACS Concepts-of-Operations-Based Functional Analysis 

AeroMACS could provide a communication link to transfer surveillance and weather information 13 , 
facilitate flight and resource management, enhance CDM, and enable exchange of aeronautical 
information in the future NAS. The tables in Appendix B document the select RTCA NAS ConOps 
(Ref. 14) found to be applicable to the proposed AeroMACS. 14 

The desired AeroMACS functional capabilities were derived from the identified NAS ConOps 
presented in Appendix B and mapped to (1) the high-level aeronautical A/G and G/G communication 
functions described in Section 4. 1.1.1 and (2) specific COCR ATS services. Table 1 1 lists the 
AeroMACS high-level functional capabilities and presents this mapping. This encompasses a top-down 
approach to the development of functional requirements. 


TABLE 1 1.— MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE SYSTEM (NAS) CONCEPTS 

OF OPERATION (ConOps) 

[Acronyms are defined in Appendix A.] 


Desired AeroMACS 
capabilities 

NAS ConOps references (Ref. 14) 

Functional 
hierarchy reference 

Communications 
operating concept and 
requirements (COCR) 
air traffic services 
(ATS) 

Enable air-to-ground 
(A/G) and ground-to- 
ground (G/G) 
communications for 
fixed-to-mobile as well as 
fixed-to-fixed services. 

S-l; S-3; S-4; 

W-2; W-3; W-8; W-9; W-10; W-12; W-13; 
W-14; W-15; 

FM-1; FM-6; FM-8; FM-12; FM-14; FM-15; 
FM 17; FM-23; 

A-2; A-6; A-12; A-15 

C. 1.1. 1.2 
C.l. 1.2.2 
C.l. 1.4.1 

D-OTIS a 

D-RVR a 

D-SIG 

D-SIGMET 

FLIPCY 

WAKE 

PPD 

Support addressed 
communication for 
delivery of information to 
individual and multiple 
users 

S-l; 

W-10; 

FM-6; FM-8 

C.l. 1.1.2 
C.l. 1.2.2 
C.l. 1.4.1 

D-OTIS a 

D-RVR a 

D-SIG 

D-SIGMET 

FLIPCY 

PPD 

Support broadcast 
communication for 
delivery of information to 
multiple users 

S-l; S-4; 

W-2; W-3; W-12; W-14; 
FM-8; 

A-12 

C.l. 1.1.2 
C.l. 1.2.2 
C.l. 1.4.1 

D-OTIS a 

D-RVR a 

D-SIG 

D-SIGMET 

WAKE 

Support delivery of real- 
time information in a 
timely manner 

S-l; S-3; 

W-16; 

FM-1; FM-2; FM-9; FM-10; FM-12; FM-15; 
FM-18; FM-25; FM-26; 

RM-3; RM-7; 

A-4; A-7; A-l 1 


D-RVR a 

D-SIG 

D-SIGMET 

FLIPCY 

WAKE 

PPD 

Enable demand, periodic, 
and event communication 

S-l; 

W-12 


All services 


13 In today’s environment both surveillance and weather information would be uplinked to the aircraft on the ground. 
In the future, a downlink may be applicable to transfer this data to the controller. 

14 Although the RTCA document describes the NAS evolution in terms of three time periods — near (up to 2005), mid 
(2005 through 2010) and far (beyond 2010) — most concepts identified in the document are applicable to the 
proposed AeroMACS, which will necessarily be implemented beyond 2010. 
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TABLE 1 1.— MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE SYSTEM (NAS) CONCEPTS 

OF OPERATION (ConOps) 

[Acronyms are defined in Appendix A.] 


Desired AeroMACS 
capabilities 

NAS ConOps references (Ref. 14) 

Functional 
hierarchy reference 

C ommunications 
operating concept and 
requirements (COCR) 
air traffic services 
(ATS) 

Accommodate a wide 
range of data types (e.g., 
surveillance reports, 
weather raw data and 
products, flight profiles, 
etc.) to support common 
situational awareness 

S-3; 

W-2; W-3; 
A- 1 ; A- 5 


All services 

Support multiple quality- 
of-service (QoS) 
provisions 



All services 

Support authentication of 
users and controlled 
access to NAS 
information (security) 

W-l 


All services 

Provide support of both 
Federal Aviation 
Administration (FAA) 
and non-FAA ground 
users 

S-l; 

FM-12; FM-14; FM-20; 
A-l 1 


All services 

Avoid single points of 
failure 

RM-6 


All services 

Provide a scalable 
solution 



All services 

Provide standards-based 
solution 



All services 


a At the time of this report D-OTIS and D-RVR are listed as part of the RTC A SC-214 scope. As noted throughout this report, 
the services are considered candidates for AeroMACS if not implemented by the Data Comm program. 
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High-level AeroMACS functional requirements can then be constructed from the functional 
capabilities in a straightforward manner, as shown in Table 12. 


TABLE 12.— AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS 


System functions 

AeroMACS high-level functional requirements 

Enable air-to-ground (A/G) and ground-to- 
ground (G/G) communications for fixed-to- 
mobile as well as fixed-to-fixed services. 

The system shall enable ground-to-air (G/A) communication for fixed-to- 
mobile users. 

The system shall enable G/A communication for mobile-to-mobile users. 
The system shall enable A/G communication for fixed-to-mobile users. 
The system shall enable A/G communication for mobile-to-mobile users. 
The system shall enable G/G communication for fixed-to-fixed users. 

Support addressed communication for 
delivery of information to individual and 
multiple users. 

The system shall support addressed communications to individual users. 
The system shall support addressed communications to multiple users. 

Support broadcast communication for 
delivery of information to multiple users. 

The system shall support broadcast communication to multiple users. 

Support delivery of real-time infonnation in a 
timely manner. 

The system shall support delivery of real-time information in a timely 
manner. 

Enable demand, periodic, and event 
communication. 

The system shall enable demand communication. 
The system shall enable periodic communication. 
The system shall enable event communication. 

Accommodate a wide range of data types 
(e.g., surveillance reports, weather raw data 
and products, flight profiles, etc.) to support 
common situational awareness. 

The system shall accommodate a wide range of data types (e.g., surveillance 
reports, weather raw data and products, flight profiles, etc.) to support 
common situational awareness. 

Support multiple QoS provisions. 

(This functional capability points toward performance requirements.) 

Support authentication of users and 
controlled access to National Airspace 
System (NAS) information (security). 

The system shall support authentication of users (security). 

The system shall support controlled access to NAS information (security). 

Provide support of both Federal Aviation 
Administration (FAA) and non-FAA ground 
users. 2 

The system shall support FAA ground users. 

The system shall support non-FAA ground users. 

Avoid single points of failure. 

The system shall avoid single points of failure. 

Provide a scalable solution. 

The system shall provide a scalable solution. 

Provide a standards-based solution. 

The system shall provide standards-based solution. 


“To support increasing collaboration among NAS users, the proposed system shall accommodate a wide range of NAS users 
by accepting NAS data from NAS data sources, both internal and external to the FAA. Users may include aircraft, airline 
operation centers, service providers, FAA users, and other Government agencies. 
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4.1.2 AeroMACS Functional System Requirements — Bottom-Up Approach 

4.1.2. 1 National-Airspace-System-Level Functional Requirements for AeroMACS Services 

Functions identified in the NAS SR-1000 (Ref. 13) — plan flights, monitor flights, control traffic, 
support flight operations, monitor NAS operations, and plan NAS usage — cut across all the AeroMACS 
capabilities shown in Table 13. Table 2 in Section 3.2.2. 1 mapped NAS-level A/G communication 
functions to NAS service capabilities, highlighting services potentially enabled by A/G voice 
communication. As expected, the NAS functions potentially enabled through an AeroMACS go well 
beyond those shown in Table 2. Consequently, Table 13 highlights the capabilities of the proposed 
AeroMACS enabling NAS functionality specified in the NAS SR-1000. The colored boxes denote 
services potentially enabled by A/G communication, with the blue boxes representing voice and/or data 
communication and the green boxes representing data communication only. 

TABLE 13.— MAPPING RELEVANT NATIONAL AIRSPACE SYSTEM (NAS) 
COMMUNICATIONS FUNCTIONS TO NAS SERVICE CAPABILITIES (REF. 13) 
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In Table 14, functional requirements applicable for an AeroMACS operating on the airport surface 
were extracted from the NAS requirements specified in the NAS SR- 1000. Unless specifically stated 
otherwise, these could apply to A/G or G/G communications for fixed-to-mobile or fixed-to-fixed 
applications. 


TABLE 14.— NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS 
[Numbers in the table correspond to communication requirements in the NAS SR-1000 (Ref. 13).] 


| NAS functions 

Communication requirements 

Plan flights 

Evaluate flight 
conditions 

The NAS shall disseminate the status of special use airspace to users. (08760) 

The NAS shall disseminate weather information to users to support flight planning. 
(27150) 

The NAS shall disseminate aeronautical information to users to support flight planning. 
(27160) 

Manage flight plans 

The NAS shall disseminate flight information to users. (00010) 

The NAS shall disseminate flight plan information to users via external data interfaces. 
(00410) 

The NAS shall disseminate flight plan information to users via air-ground data 
communications. (00970) 

The NAS shall disseminate flight data summaries to users. (00070) 

The NAS shall disseminate flight plans to users. (02160) 

The NAS shall disseminate flight plan clearances to users. (02900) 

Monitor 

flights 

Collect aircraft 

navigation 

information (collect 

dependent 

surveillance 

information) 

The NAS shall retrieve actual flight information. (10000) 

The NAS shall acquire actual flight infonnation from aircraft outside of independent 
surveillance coverage. (03320) 

Monitor aircraft 
status 

The NAS shall respond to emergency transmission received via radio communications. 
(12600) 

The NAS shall respond to emergency transmissions received via data link. (12620) 

The NAS shall disseminate essential infonnation on missing aircraft. (13130) 

Report 
(disseminate) 
aircraft status 

The NAS shall display position information, to specialists, for aircraft that were detected 
independent of aircraft equipage in qualifying aerodromes. (24530) 

The NAS shall transmit conflict-free flight path recommendations to expedite resolution 
of emergency situations. (12820) 

The NAS shall disseminate aircraft flight infonnation for each controlled aircraft to 
specialists. (02720) 

The NAS shall disseminate the current location for each participating aircraft to ATCSCC 
[air traffic control system command center] specialists. (10940) 

The NAS shall disseminate the current location for each participating aircraft to Traffic 
Management Coordinators. (10980) 

Control 

traffic 

Address active 
aircraft conflicts 

The NAS shall disseminate recommended collision avoidance maneuvers to users. 
(03690) 

Control aircraft 

The NAS shall disseminate aeronautical infonnation to users via air-ground data 
communications. (07440) 

Coordinate traffic 
control distribution 

The NAS shall acquire pilot reports (PIREP). (05530) 

The NAS shall disseminate weather advisories via direct specialist to pilot 
communications. (09290) 
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TABLE 14.— NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS 
[Numbers in the table correspond to communication requirements in the NAS SR-1000 (Ref. 13).] 


j NAS functions 

Communication requirements 

Support 

flight 

operations 

Manage weather 
information 

The NAS shall maintain communication links adequate to avoid user delay in gaining 
access. (07090) 

The NAS shall disseminate weather information to users continuously. (07110) 

The NAS shall disseminate current weather effect along the users proposed flight path. 
(07470) 

The NAS shall disseminate forecast weather in effect along the users proposed flight path. 
(07480) 

The NAS shall disseminate intensity levels of weather by route of flight to users. (08260) 
The NAS shall disseminate intensity levels of weather by geographic area to users. 
(08300) 

The NAS shall disseminate weather advisories to users in response to a request. (09300) 

The NAS shall broadcast the latest approved aerodrome conditions on communications 
media accessible by aircraft on the ground. (09340) 

The NAS shall broadcast the latest approved terminal area conditions on communications 
media accessible by aircraft on the ground. (09360) 

The NAS shall respond to user requests for weather information from NAS facilities 
through common carrier communications networks. (09370) 

The NAS shall disseminate selected weather information directly to appropriately 
equipped aircraft. (09420) 

The NAS shall provide flexible and convenient access to required weather information to 
users. (19380) 

Operate navigation 
aids'* 

The NAS shall disseminate navigational accuracy correction values for supplemental 
navigation systems to users. (17040) 

The NAS shall disseminate correction values for navigational aids to users. (16790) 

The NAS shall disseminate available supplemental terminal navigation guidance 
information error correction values to users. (14820) 
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TABLE 14.— NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS 
[Numbers in the table correspond to communication requirements in the NAS SR-1000 (Ref. 13).] 


j NAS functions 

C ommunication requirements 

Monitor 

NAS 

operations 

Monitor NAS flight 
operations 

The NAS shall disseminate future delay advisories in effect along the users proposed 
flight path. (07500) 

The NAS shall disseminate traffic advisories upon user request. (09120) 

The NAS shall provide traffic advisories to aircraft on the surface. (30270) 

Maintain NAS 
infrastructure 

The NAS shall disseminate airway usage information to users. (00030) 

The NAS shall disseminate route usage information to users. (00050) 

The NAS shall disseminate aeronautical information to users via external data interfaces. 
(07430) 

The NAS shall disseminate aeronautical information per user request. (07130) 

The NAS shall disseminate aeronautical information upon user request continuously. 
(07340) 

The NAS shall disseminate aeronautical data for a maximum of 8 specified locations per 
request. (07400) 

The NAS shall disseminate the status of supplemental navigation systems to users. 
(17010) 

The NAS shall disseminate status of supplemental navigation systems to users. (16770) 
The NAS shall disseminate flow control information to users via external data interfaces. 
(07920) 

The NAS shall disseminate derived restrictions to the user. (11700) 

The NAS shall disseminate alternate courses of action relative to flight restrictions to 
users. (11790) 

The NAS shall disseminate terrain infonnation compliant with terrain, ground and 
obstacle infonnation accuracy requirements, to users upon request. (03900) 

The NAS shall disseminate manmade obstacle infonnation compliant with terrain, ground 
and obstacle information accuracy requirements, to users upon request. (03940) 

The NAS shall disseminate ground infonnation compliant with terrain, ground and 
obstacle infonnation accuracy requirements, to users upon request. (25520) 

The NAS shall disseminate filtered terrain infonnation to users. (25560) 

The NAS shall disseminate filtered ground information to users. (25570) 

The NAS shall disseminate filtered manmade obstacle infonnation to users. (25580) 

Plan NAS 
usage 

Plan traffic flow 

The NAS shall disseminate preferred route infonnation at least 24 hours prior to it 
becoming effective. (07280) 

The NAS shall disseminate military air traffic control plans related to national 
emergencies. (16140) 

The NAS shall disseminate flow control information to users via external data interfaces. 
(07920) 

The NAS shall disseminate interfacility traffic flow plans. (1 1970) 

The NAS shall disseminate derived restrictions to the user. (11700) 

The NAS shall disseminate derived alternative courses of action to the user. (11720) 

The NAS shall detennine flight restrictions for specific aircraft. (11760) 

The NAS shall disseminate flight restrictions to users. (11770) 

The NAS shall disseminate alternate courses of action relative to flight restrictions to 
users. (1 1790) 

Assess traffic flow 
performance 

The NAS shall disseminate reports on equipment performance. (18870) 
The NAS shall disseminate reports on maintenance activities. (18880) 

The NAS shall disseminate reports on equipment repair activities. (18890) 


“These services are typically provided via satellite communication (SATCOM) but could be provided via a ground-based system. 
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4.1.2.2 National-Airspace-System-Level Functional Requirements for AeroMACS 
Infrastructure 

The following is a summary of NAS infrastructure (communications) requirements found applicable 
to the proposed AeroMACS as documented in the NAS SR-1000 (Ref. 13). The list supports the high- 
level functional requirements presented in the document. 

• The NAS shall provide data channels in the frequency band appropriate for air-ground data 
communications equipment for data communications coverage for both civil and military users. 
(19940) 

• The NAS shall automate communications capabilities to reduce specialist and user workload. 

( 20210 ) 

• The NAS shall provide air-ground communications continuously. . . (part of 20330) 

• The NAS shall provide reconfiguration of communications capabilities without degradation of 
air-ground voice or data communications. (20380) 

• The NAS shall support peak busy hour exchange of data including short-term peaks that may 
occur within the peak hour, with minimal change in the data transmission response times and no 
loss of data. (20760) 

• The NAS shall reconfigure communication capabilities to support changes in operating 
responsibilities. (20800) 

• The NAS shall provide processing and communications capacities to support the required backup 
capabilities and to meet the response time requirements while maintaining safe separation of all 
aircraft receiving ATC services (i.e., both normal and backup sectors) from the backup facilities. 
(21670) 

• The NAS shall provide configurable communications. (32120) 

4.2 AeroMACS Performance Requirements 

4.2.1 National- Airspace-System-Level Performance Requirements Applicable to AeroMACS 

Performance requirements were derived to define system capabilities based on the functional 
requirements developed in preceding sections. Table 15 summarizes NAS performance requirements 
found to be relevant to the proposed AeroMACS as documented in the NAS SR-1000 (Ref. 13). Note 
that these are high-level NAS requirements that do not specify how they should be implemented. A/G and 
G/G communications are considered to be possible implementation solutions. 


TABLE 15.— NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS 
[Numbers in the table correspond to performance requirements in Ref. 13.] 


NAS function 

Perfo nuance requirement 

Control traffic 

The NAS shall disseminate hazardous weather avoidance recommendations to users within 1 minute of 
request. (08440) 

The NAS shall communicate aircraft actions to users within 1 minutes of implementing a weather avoidance 
plan. (08460) 

The NAS shall alert participating aircraft to predicted conflicts with obstructions within 10 seconds of 
prediction. (09170) 

The NAS shall notify users of non-adherence to ATC clearance within 10 seconds of the detection of the 
deviation. (02010) 

The NAS shall alert appropriately equipped users to the collision danger within 10 seconds after the 
prediction is made. (03660) 
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TABLE 15.— NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS 
[Numbers in the table correspond to performance requirements in Ref. 13.] 


NAS function 

Performance requirement 

Support flight 
operations 

The NAS shall disseminate a requested summary of hazardous weather for any airspace in the continental 
United States within a mean response time 3.0 seconds of the request. (08060) 

The NAS shall notify users affected by the presence of hazardous weather within 2 minutes of acquisition. 
(08170) 

The NAS shall update hazardous weather broadcasts at least once every 30 minutes. (09400) 

The NAS shall disseminate automated weather observations once per minute to designated interfaces. 
(05270) 

The NAS shall disseminate terminal area hazardous weather information to users within one minute of 
detection. (06990) 

The NAS shall display requested routine weather information to the user within a mean response time of 
3.0 seconds of the request. (23380) 

The NAS shall display requested routine weather information to the user within a 99th percentile response 
time of 5.0 seconds of the request. (23390) 

The NAS shall display requested routine weather information to the user within a maximum response time 
of 10.0 seconds of the request. (23400) 

The NAS shall disseminate a requested summary of hazardous weather for any airspace in the continental 
United States within a 99th percentile response time of 5.0 seconds of the request. (23510) 

The NAS shall disseminate a requested summary of hazardous weather for any airspace in the continental 
United States within a maximum response time of 10.0 seconds of the request. (23520) 

Monitor NAS 
operations 

The NAS shall alert users to a full navigation system failure affecting NAS operations within 10 seconds of 
the failures detection. (17110) 

The NAS shall alert users to a partial navigation system failure affecting NAS operations within 10 seconds 
of the failures detection. (17130) 

The NAS shall disseminate the results of Traffic Management Coordinator capacity projection requests 
within 99th percentile response time of 5.0 seconds of the request. (10820) 

The NAS shall disseminate the results of Traffic Management Coordinator capacity projection requests 
within a maximum response time of 10.0 seconds of the request. (10820) 

The NAS shall disseminate the results of Traffic Management Coordinator demand projection requests 
within the 99th percentile response time of 5.0 seconds of the request. (10850) 

The NAS shall disseminate the results of Traffic Management Coordinator demand projection requests 
within a maximum response time of 10.0 seconds of the request. (10850) 
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TABLE 15.— NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS 


[Numbers in the table correspond to performance requirements in Ref. 13.] 


NAS function 

Performance requirement 

Plan NAS usage 

The NAS shall disseminate requested flow control advisory information to users within a mean response 
time of 3.0 seconds of the request. (07890) 

The NAS shall disseminate scheduled flight activity information in military special use airspace within 
1 minute of request. (08900) 

The NAS shall disseminate requested delay advisory information to users within a mean response time of 
3.0 seconds of the request. (07900) 

The NAS shall alert users not more than 10 seconds after any failures of navigation guidance affecting 
operations within the NAS. (16810) 

The NAS shall alert users not more than 10 seconds after any failures of portions of navigation guidance 
affecting operations within the NAS. (16820) 

The NAS shall alert users within 10 seconds, of failures to navigation guidance that affect operations. 
(17150) 

The NAS shall alert users within 10 seconds, of failures to portions of navigation guidance that affect 
operations. (09590) 

The NAS shall assure ground-air transmission time for data messages not exceed 6 seconds. (20090) 

The NAS shall provide retrievable air-ground data messages within 30 minutes and from “off-line” storage 
within 60 minutes. (20270) 

Individual air-ground data messages shall be retrievable from “off-line” storage within 5 minutes of a 
request by authorized NAS personnel. (20280) 

The NAS shall strive to restore critical system service to users/specialists within 6 seconds of failure 
(22900) 

The NAS shall strive to restore essential system service to users/specialists within 10 minutes of failure. 
(22910) 

The NAS shall disseminate requested aeronautical information to users within a mean response time of 

3.0 seconds of the request. (23580) 

The NAS shall disseminate requested aeronautical information to users within a 99th percentile response 
time of 5.0 second of the request. (23590) 

The NAS shall disseminate requested aeronautical information to users within a maximum response time of 

10.0 seconds of the request. (23600) 

The NAS shall disseminate requested flow control advisory information to users within a 99th percentile 
response time of 5.0 seconds of the request. (23950) 

The NAS shall disseminate requested flow control advisory information to users within a maximum 
response time of 10.0 seconds of the request. (23960) 

The NAS shall disseminate requested delay advisory information to users within a 99th percentile response 
time of 5.0 seconds of the request. (23970) 

The NAS shall disseminate requested delay advisory information to users within a maximum response time 
of 10.0 seconds of the request. (23980) 
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4.2.2 Communications Operating Concept and Requirements (COCR) Performance 
Requirements Applicable to AeroMACS 

The performance requirements shown in Table 16 resulted from the operational performance 
assessment conducted as part of the COCR (Ref. 11). That assessment determined the performance that a 
system or service must achieve and led to a determination of the availability, integrity, and transaction 
times. Performance requirements were driven by operational needs and safety requirements as well as 
other assessments (e.g., information security) to determine overall communication performance 
requirements. 

The more stringent of the safety obj ectives and operational requirements for each parameter was used 
to determine the communication performance requirements. The operational requirements are driven by 
the type of exchange (e.g., trajectory change and general information) and the domain in which the 
service was offered. 

Values in Table 16 are based on COCR ATS future radio system performance requirements (Ref. 11) 
for the select services with the most stringent requirements presented. For example, the WAKE service is 
a driving service for defining the latency requirements in the APT, TMA, and ENR domains. 

Performance requirements should be revisited at a later stage in the system development process to 
reflect the most current ConUse and services selection. 


TABLE 16.— AEROMACS DATA REQUIREMENTS 


Service type 

Confidentiality 

Latency, 

sec 

Integrity 

Availability of 
provision 

Addressed 

Medium 

1.4 

5.0xl0“ 8 

0.999995 

Broadcast 

Medium 

0.4 

5.0xl0“ 8 

0.999995 


4.3 Other AeroMACS Requirements 

4.3.1 Spectrum Requirements Applicable to AeroMACS 

One of the main objectives of the proposed AeroMACS network is to increase communications 
system capacity. A channel plan will be developed driven by frequency availability to support broadband 
services. Section 6.2.2 discusses channelization methodology for AeroMACS design. 

The proposed system should provide seamless operations around the globe. International standards 
are being developed to achieve full interoperability. 

Table 17 summarizes NAS spectrum requirements applicable to the proposed AeroMACS as 
documented in the NAS SR- 1000 (Ref. 13). 


TABLE 17.— NATIONAL AIRSPACE SYSTEM (NAS) SPECTRUM 
REQUIREMENTS APPLICABLE TO THE PROPOSED AEROMACS 
[Numbers in the table correspond to perfonnance requirements in the NAS SR-1000 (Ref. 13).] 


Category 

Perfonnance requirement 

Secure spectrum with 
the Federal Aviation 
Administration (FA A) 

The NAS shall secure and protect national radio spectrum for the FAA and the US Aviation 
community. (32470) 

The NAS shall coordinate national spectrum allocation programs. (19190) 

The NAS shall establish new systems spectrum development activities compatible with projected 
national use. (19290) 

Secure frequency for 
the FAA 

The NAS shall establish national frequency allocation programs. (19170) 

The NAS shall establish new systems frequency development activities compatible with current 
national use. (19230) 

The NAS shall establish new systems frequency development activities compatible with projected 
national use. (19270) 
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TABLE 17.— NATIONAL AIRSPACE SYSTEM (NAS) SPECTRUM 
REQUIREMENTS APPLICABLE TO THE PROPOSED AEROMACS 
[Numbers in the table correspond to performance requirements in the NAS SR-1000 (Ref. 13).] 


Category 

Perfonnance requirement 

Secure international 
spectrum 

The NAS shall establish new systems spectrum development activities compatible with current 
national use. (19250) 

The NAS shall comply with national standards to avoid the interference of new systems with existing 
systems. (19310) 

The NAS shall coordinate national spectrum management assistance programs. (19210) 

The NAS shall disseminate en route navigational guidance such that ambiguities in guidance 
information have a minimal impact on NAS operations. (13960) 

Manage international 
spectrum 

The NAS shall comply with international standards to avoid the interference of new systems with 
existing systems. (32090) 


By International Telecommunications Union (ITU) regulation, AM(R)S allocated spectrum can 
only be used to support aeronautical mobile safety or regularity of flight services. However, in the United 
States, fixed applications that directly impact safety and regularity of flight may be provisioned by an 
AM(R)S mobile communications network infrastructure. 

4.3.2 User Requirements Applicable to AeroMACS 

Table 1 8 summarizes aviation user requirements based on those documented in Reference 5 1 and 
found to be potentially applicable to AeroMACS. 

TABLE 18.— AVIATION USER REQUIREMENTS 

The system shall be capable of supporting all categories of users including the following (Ref. 46): 

1 . Scheduled air transport carriers (including international, trunk, regional, commuter and air freight carriers) 

2. Nonscheduled air carriers 

3. General Aviation (GA) (including operators of turbine-powered and reciprocating-engine aircraft) 

4. Nonscheduled air carriers 

5. General Aviation (GA) (including operators of turbine-powered and reciprocating-engine aircraft) 

6. Rotorwing Aircraft (including helicopters and gyrocraft) 

7. Unpowered aircraft (including gliders and lighter-than-air) 

8. Military aircraft 

9. Certain ground and maritime vehicles (e.g., airport service vehicles, those vehicles coordinating in a search-and-rescue 
mission) 

The new system shall satisfy any data communications requirements for use in any authorized category of communications 
service including ATS, AOC, and AAC. 

The avionics equipment shall communicate with any compatible ground system. 


4.3.3 Regulatory Requirements Applicable to AeroMACS 

The following list summarizes regulatory requirements based on those documented in Reference 5 
and found to be potentially applicable to AeroMACS. 

• The system shall comply with AM(R)S spectrum allocation requirements. 

• The system shall comply with the U.S. ATS and AOC service rules and regulations. 

• The system shall comply with the U.S. Federal aviation regulations. 

• The system shall support the requirements for message priority capability. 

Article 44 of ITU Radio Regulations defines the order of priority for communications in the 
aeronautical mobile service and the aeronautical mobile-satellite service. Table 19 shows the ITU priority 
levels (from 1 to 1 0 respectively from the highest priority to the lowest priority) and maps them to the 
ATS and AOC services defined by the COCR. Only services identified by Reference 9 as potential ATS 
or AOC applications for provision by AeroMACS are included in the table. 
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TABLE 19.— MAPPING OF ITU PRIORITY LEVELS TO COCR SERVICES (REF. 38) 


ITU Priority Level 

COCR Services | 

ATS 

AOC a 

1 

Distress calls, distress message, and distress traffic 



2 

Communications preceded by the urgency signal 



3 

Communications related to radio direction-finding 



4 

Flight safety messages 

D-RVR 

D-OTIS 

FLIPCY 

D-SIG 

WAKE 

D-SIGMET 

PPD 

Notice to Airmen (NOTAM) 

Flight Plan Data (FLTPLAN) 

Load Sheet Request/Transfer 
(LOADSHT) 

Update Electronic Library (UPLIB) 

5 

Meteorological messages 


Textual Weather Reports 
(WXTEXT) 

Real-time Weather Reports for Met 
Offices (WXRT) 

Graphical Weather Information 
(WXGRAPH) 

6 

Flight regularity messages 


Flight Status (FLTSTAT) 

Maintenance Problem Resolution 
(MAINTPR) 

Real-Time Maintenance Information 
(MAINTRT) 

AOC Data Link Logon (AOCDLL) 

Out-Off-On-In (OOOI) 

Cabin Log Book Transfer 
(CABINLOG) 

Technical Log Book Update 
(TECHLOG) 

Fuel Status (FUEL) 

Gate and Connecting Flight Status 
(GATES) 

Engine Performance Reports 
(ENGINE) 

Flight Log Transfer (FLTLOG) 

EFFuplink b 

EFFdownlink b 

CONF b 

PERF b 

VQAR b 

CVM b 

CabMAINTTRT b 

TELEMED b 

REFUEL” 

deicing” 
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TABLE 19.— MAPPING OF ITU PRIORITY LEVELS TO COCR SERVICES (REF. 38) 


ITU Priority Level 

COCR Services | 

ATS 

AOC a 

7 

Messages related to the application of the United 
Nations Charter 



8 

Government messages for which priority has been 
expressly requested 



9 

Service communications related to the working of 
the telecommunication service or to 
communications previously exchanged 



10 

Other aeronautical communications 


Free Text (FREETEXT) 
Software Loading (SWLOAD) c 


“Most of the AOC services listed in the COCR are included here as they are either airport-surface-only applications or applicable 
to both surface and in-the-air scenarios. 

b These are additional AOC services not specified in the COCR and therefore not addressed in the ITU Informational Paper ACP- 
WGF 1 9/IPO 1 as all other services. 

“Although listed in the COCR, this service may not be applicable application for a wireless communications system. 

4.3.4 Safety and Security Requirements Applicable to AeroMACS 

A fundamental safety requirement is that new communications systems shall not cause degradation in 
safety when compared with the existing communications systems. The overall objective is to improve 
safety. A C-band initial safety and security analysis and the associated requirements applicable to 
AeroMACS are covered in separate documents (Refs. 45 and 47). 

4.4 Guidance for the Development of AeroMACS Requirements Based on IEEE 802.16- 
2009 

The preceding sections presented high-level functional and performance requirements applicable to 
AeroMACS that encompass most of the known A/G and G/G communications services for mobile-to- 
fixed and fixed-to-fixed applications on the airport service. They should be considered NAS high-level 
guidance in the development of specific system requirements necessary for any particular service for 
implemented over AeroMACS. 

Typically high-level requirements are technology independent. Perhaps unique to the development of 
the AeroMACS requirements is the identification a priori, by virtue of the extensive FCS technology 
assessment, of the recommended technology by which AeroMACS will be implemented, that is, IEEE 
802.16-2009. This allows the identification and development of quite specific requirements depending on 
the desired application or service to be provided. The following sections provide a preliminary approach 
for identifying and developing AeroMACS requirements in the context of the IEEE 802.16-2009 
broadband communications standard and its characteristics. 

4.4.1 Introduction 

The applications discussed in Section 3.5.3 require the support of several types of communication 
services. Much of the initial requirements analysis work was done in the COCR study (Ref. 11), which 
conducted analysis to specify requirements for continuity, integrity, availability of provision, and 
availability of use for various ATS communication services. The services analyzed were primarily 
narrowband services, but the study indicated the level of performance that would be needed by a 
wideband service as well. 

An initial safety analysis was carried out for future airport surface communication systems that 
considered the possibility of wideband communication systems (Ref. 48). This analysis dealt with various 
aspects of hazards and safety risks relative to ConUse and provided initial top-level risk assessments. 
Safety risk assessments deal with the criticality of communication services and the ability of these 
services to maintain levels of performance in operation. The results from a safety and reliability analysis 
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will help determine link performance requirements and the level of redundancy needed in the 
communication system. In addition, a safety analysis will help determine the monitoring and maintenance 
intervals needed for the communication system and the supporting network management functions. 

Security levels and services also are considered in developing requirements that can be applied at the 
link/MAC and physical layers. At the physical layer, transmission security may be required to prevent 
unauthorized monitoring or spoofing of the transmitted signals. At the MAC layer, low-level 
authentication and identification may be needed. Security above the link and local network layers will 
include message encryption and higher level authentication services. 

These are important inputs to developing a quality-of-service (QoS) protocol/policy and physical 
layer requirements for AeroMACS. 

4.4.2 Classes of Communications Services for AeroMACS 

The applications described in Section 3.5.3 require communication services to perform their 
functions. The following subsections give brief descriptions of classes of communication services that 
may be required. For this discussion, a “point” is a central source or user of data, and “multipoint” means 
that the data traffic is sent to multiple users. This does not refer to the AeroMACS network architecture of 
a central BS (point) servicing multiple subscriber stations (SSs — multipoint). 

4.4.2. 1 Low-to-Medium-Speed Point-to-Point Data Link 

This link transports data from a sensor or ground station to a processing or monitoring unit. Data rates 
are low to moderate (<200 kilobits per second (kbps)). These links can be part of a polling network where 
several links are tied to the central station. 

4.4.2.2 High-Speed Point-to-Point Data Link 

A high-speed data link can be used to link sensors that produce high-speed data to a central processor, 
or to link multisensor network access points or a subnetwork to a larger network. Data rates >200 kbps 
are needed. 

4.4.2.3 Point-to-Multipoint Broadcast Data 

This type of communication service enables the multicast or broadcast of scheduled or priority 
messages to a large group of users or a selected subset of users (multipoint). Data updates and critical 
messages will have low to moderate data transmission rates (<200 kbps). 

4.4.2.4 Point-to-Point Command and Control Data 

This type of service is for near-real-time control of a device or system. It relies on short-turnaround 
feedback from the device being controlled. Control of runway lighting is one example for this type of 
service. The command UL and feedback link are low rate (<100 kbps), but they require low error rates. 
The UL may carry higher data rates (e.g., video at <2 megabits per second (Mbps)) and can tolerate 
higher error rates than the control li nk . 

4.4.2. 5 Voice Network 

Digital voice networks have several advantages over analog voice circuits. For example digital voice 
circuits can be encrypted. However, they have requirements on maximum delay corresponding to the 
human response times (typically less than 200 msec one way). This usually dictates a time-division 
multiple-access (TDMA) system to guarantee maximum delay time. Capacity requirements will depend 
on the number of voice circuits used. 
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4.4.2.6 Video Link 

Depending on the resolution and frame rates needed for an application, video transmission can require 
significant capacity, typically on the order of 1 Mbps for a single link. Thus, a relatively small number of 
video circuits per BS sector (in comparison to a voice circuit) are likely to be supported in a multiservice 
communication system. 

4.4.2.7 Multimedia 

Multimedia services combining voice, data, and video can require a large amount of communication 
resources depending on how the services are combined for use. For CDM, voice plus data (graphics) may 
be all that is needed. An example would be an application like Cisco’s WebEx. The addition of video to 
CDM will require a significant increase in demand for capacity from the network. 

4.4.2.8 Basic Mobile 

This class of communication service requires the necessary QoS and network functions for handoff 
between BS sectors to support basic voice and data services. 

4.4.2.9 Enhanced Mobile 

This class of mobile service provides increased capacity to handle interactive applications such as 
CDM while on the move. 

4.4.3 Developing AeroMACS Service Quality-of-Service Requirements Based on IEEE 802.16- 
2009 

Developing a QoS function for a modem communication system involves three main areas of 
consideration: 

(1) Defining a set of QoS parameters and metrics that can be used to monitor and classify different 
grades of communication services 

(2) Determining service priorities and preemption if needed 

(3) Developing a protocol for managing and scheduling services 

The IEEE 802.16-2009 standard includes five QoS categories. These categories use a number of 
perfomiance parameters to quantify performance. The five QoSs included in the IEEE 802.16-2009 
standard follow: 

(1) Unsolicited grant service (UGS) supports fixed-size data packets and allocated capacity. Digital 
voice circuit over the Internet (VoIP) is an example. 

(2) Real-time polling services (rtPS) are designed to support networked video and voice applications 
on a high-speed network that supports multiple streams. 

(3) Non-real-time polling service (nrtPS) supports delay-tolerant data streams that transmit at 
periodic intervals, such as file transfers. 

(4) Best-effort service provides a best effort for delivering data packets without guaranteeing 
delivery. This is the type of service normally provided by the Internet. 

(5) Extended real-time variable rate (ERT-VR) service supports real-time applications that can have 
variable packet sizes. Digital voice with silence suppression is an example. 
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Table 20 relates the five QoS categories to the applications that will benefit from the QoS category 
and the parameters that define each QoS category (Ref. 49). 


TABLE 20.— IEEE 802.16-2009 QUALITY OF SERVICE CATEGORIES AND DEFINING PARAMETERS 


Defining parameters 

Unsolicited grant 
service, 

UGS 

Real-time 

polling 

service, 

rtPS 

Non-real-time 
polling service, 
nrtPS 

Extended real- 
time polling 
service 

Best 

effort 

Applications 

Traffic over T1 or 
El lines, 
VoIP a without 
silence suppression 

Streaming 
audio and 
streaming 
video 

FTP and TCP b 
applications that 
require a minimum 
data rate 

VoIP with 
voice-activity 
detection 
(bursty traffic) 

Web 

browsing 
and file 
transfer 

Real-time service flow 

X 

X 


X 


Fixed-size data packets 

X 



X 


Scheduled packet transmission 

X 

X 


X 


Minimum reserve rate 


X 

X 



Maximum sustained rate 


X 

X 


X 

Maximum latency tolerance 


X 




Time jitter tolerance 

X 



X 


Traffic priority 


X 

X 

X 

X 

Dynamic traffic allocations 




X 


Unicast polls (guaranteed 
service request opportunities in 
congestion) 



X 




a VoIP, digital voice over Internet Protocol. 

b FTP, File Transfer Protocol; TCP, Transmission Control Protocol. 
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4.4.4 Quality of Service Support of AeroMACS Communication Services 

Table 21 shows an analysis of the communications services that were discussed in Section 4.4.2 with 
example airport applications and applicable QoS service classes. Typical values of performance are 
included for data rate, packet error rate (PER), delay (time latency), and time jitter. 


TABLE 21.— COMMUNICATION SERVICE REQUIREMENTS 
[Acronyms are defined in Appendix A.] 


Communication 

service 

Example airport 
application 

Quality-of-service 
(QoS) class 

Performance 

parameters 

Typical 

values 3 

Supported 
by IEEE 
802.16-2009 

Low-to-medium- 
speed point-to-point 
data link 

Backup for sensor cable 
link (i.e., weather 
sensor) 

nrtPS 

Data rate 
PER 
Delay 
Jitter 

100 kbps 
l.OxlO -3 
1 sec 
100 psec 

Yes 

High-speed point- 
to-point data link 

Backbone-linking BS; 
link to relay gateway 
node in remote area 

UGS 

Data rate 
PER 
Delay 
Jitter 

1 Mbps 
l.OxlO -3 
100 msec 
100 nsec 

Yes 

Point-to-multipoint 
broadcast data 

Scheduled broadcast of 
weather info, NOT AM 

nrtPS 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -3 
1 sec 
<1 psec 

Yes 

Point-to-point 
command and 
control data 

Remote operation of 
ADS-B ground station 

rtPS 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -6 
100 msec 
<1 psec 

Yes 

Command and 

control 

network 

Operation of surface 
devices at remote airport 

Best effort 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -4 
200 msec 
<10 psec 

Yes 

Digital voice 
network 

Provide N circuits for 
ATC or AOC operations 

UPS; 

ERT-VR service 

Data rate 
PER 
Delay 
Jitter 

10 kbps x N 
l.OxlO -3 
100 msec 
<100 psec 

Yes 

Point-to-point video 
link 

Airport surveillance; 
robotic vehicle 

UGS 

Data rate 
PER 
Delay 
Jitter 

600 kbps 
l.OxlO -3 
200 msec 
<10 psec 

Yes 

Basic mobile 

Handoff control for 
voice; low-speed data 
sessions 

UGS 

Data rate 
PER 
Delay 
Jitter 

200 kbps 
l.OxlO -3 
200 msec 
<10 psec 

Yes 

Multimedia 

CDM 

rtPS 

Data rate 
PER 
Delay 
Jitter 

1 Mbps 
l.OxlO -3 
100 msec 
<10 psec 

Yes 


‘ i End-to-end delay, one direction. 
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These typical performance parameters are for the physical and link-layer requirements for individual 
communication services. The actual values will depend on the architecture of the communication 
network, the size of the network, and the provisions for redundant communication support. The 
performance values shown in the table are typical of the type of communication service offered. For 
example, one-way voice delay is derived from subjective analysis involving human reactions in human 
conversation with push-to-talk communications. Jitter requirements are somewhat dependent on the 
implementation — for example, the extent to which data buffering is used. Packet error rate performance 
typically depends on the use of retransmissions and the size of the message. Future work should refine 
these performance values according to the specific services to be implemented. 

The final column of Table 21 is an assessment of whether the requirement is supported by the 
performance of a system that is based on the IEEE 802.16-2009 standard. The communications systems 
and their operating requirements are expected to be supported in all cases that were examined. 
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5.0 Architectural Description 

5.1 Initial Surface Communications System Architecture 

This section describes a system architecture framework for an airport surface communications 
reference model that can be applied at all airport installations. The number of components to be deployed 
will vary according to the size and data capacity needs of the airport. The communication architecture is 
based on the IEEE 802.16 standard for the network functions with the IEEE 802.16e-2005 amendment 
(Ref. 19), now updated to the IEEE 802.16-2009 standard for the mobile air interface. 


5.2 Overview 

The primary mode for operation on an IEEE 802.16-2009-based system is a point-to-multipoint 
architecture. Figure 25 depicts a notional wireless point-to-multipoint system in an airport context. 

In this architecture, SSs, which include fixed and portable nodes and mobile stations (MSs) are 
wirelessly linked to the BS access points. The BSs are linked to a common access service network (ASN) 
which manages services among BSs. The ASN can include one or more BSs and could be localized to one 
part of the airport (for example, an area assigned to a major carrier). For a small number of BSs, 
distributed ASN functions can be used that are installed at each BS. The ASNs are li nk ed to a 
Connectivity Service Network (CSN) through gateways (not shown in Figure 25). The CSN provides 
access to services on the airport intranet and fire-walled access to the Internet. 
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Figure 25. — Airport point-to-multipoint communications service. Acronyms are defined in Appendix A. 
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AeroMACS is envisioned to provide communications for both mobile and fixed infrastructures. An 
AeroMACS network can support fixed infrastructure in areas of scarce communications, providing wide 
bandwidth wireless li nks in place of cables that can be expensive and disruptive to install. Once an 
AeroMACS network is installed at an airport, a communications link can be instantiated by simply 
placing an AeroMACS radio at the remote data site interfaced through Ethernet ports, and by 
programming the network to authenticate and authorize service for the remote data terminal. AeroMACS 
provides the flexibility to quickly implement new links to remote sites for primary, backup, and 
emergency communications. The benefit that AeroMACS provides for mobile application 
communications is unequaled in terms of flexibility and traffic bandwidth. 

5.3 IEEE 802.16 Network Architecture 

The IEEE 802.16 Network Working Group has developed a network reference model to assist in the 
deployment of IEEE-802. 16-2009-based systems. It is designed to enable interoperability of vendor 
equipment and to provide a structure for the deployment of new systems. The architecture is Internet 
Protocol (IP)-based, meaning it relies on IP addressing to provide secure connectivity between users and 
access to common services. Figure 26 depicts a top-level view of this architecture. 



The MS nodes can be anything mobile: aircraft, service vehicles, emergency, or other vehicles and 
pedestrians. The fixed SS nodes are stationary sites that could be surveillance weather stations, radar sites, 
or the equipment in operations buildings located on the airport surface. In AeroMACS, MS and SS nodes 
are both referred to as SS, since all user stations are handled as if they were mobile. The hardware for 
both is compliant with the mobile standards, whether physically mobile or stationary. 

SS nodes are linked through wireless connections to the BS access points. There can be multiple SS 
nodes assigned to a single BS. Mobile SS nodes are transitory and must be serviced by a handoff protocol 
that enables the mobile SS to maintain connected service while moving between access point coverage 
areas. The BSs are connected to an access network that includes a gateway IP router. The access network 
manages the ASN to ensure its proper operation at the physical and MAC levels. This includes the 
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management of mobile and stationary SSs operating within the ASN. It also provides access to higher 
level services through the access service network gateway (ASN-GW). The CSN provides connectivity to 
the closed airport intranet and fire-walled access to the open Internet. The airport intranet hosts local IP- 
based servers which provide various data services and applications to authorized airport users. 

The ASN-GW aggregates subscriber and control traffic from BSs within an access network. It has an 
important role in subscriber management, network optimization, and forwarding of all SS traffic. 

The BS nodes identified in this architecture will often have multiple coverage sectors using multiple 
radios, each with a directional transmit/receive antenna. Each radio and antenna pair forming a coverage 
sector is referred to as a base transceiver station (BTS). 

The IEEE 802.16 network architecture further defines functional interfaces between the major 
components of the model as listed in Table 22. Eight functional interfaces that are defined within the 
network and between networks are listed in the table. The four interfaces shown in the figure (Rl, R2, R3, 
and R6) are defined in Table 22. Three interfaces (R4, R5, and R7) are defined that would apply to 
airports with more than one ASN, gateway (GW), or CSN, such as when multiple service providers are 
present. 


TABLE 22.— SELECTED IEEE 802.16 NETWORK INTERFACE DEFINITIONS 


[Acronyms are defined in Appendix A.] 


Interface reference 
point 

Functional entities 

Functions 

Rl 

SS and the ASN 

Implements the air interface (IEEE 802.16-2009) specifications and 
may additionally include protocols related to the management plane. 

R2 

SS and CSN 

Provides authentication, service authorization, IP host configuration 
management, and mobility management. This is only a logical interface 
and not a direct protocol interface between the ASN and CSN. 

R3 

ASN and CSN 

Supports AAA [authentication, authorization, and accounting], policy 
enforcement and mobility management. R3 also encompasses the bearer 
plane methods (e.g. tunneling) to transfer IP data between the ASN and 
the CSN. 

R4 

ASN and ASN 

A set of control and bearer plane protocols that originate/terminate 
within the ASN that coordinates SS mobility between ASNs. 

R5 

CSN and CSN 

A set of control and bearer plane protocols to support mobility between 
networks if multiple networks (airports) are supported by multiple CSNs 
and mobility handoff is needed. 

R6 

SS and ASN-GW 

A set of control and bearer plane protocols for communication between 
the BS and the ASN-GW. Consists of intra-ASN bearer paths and IP 
tunnels for mobility tunnel management. R6 may also be a conduit for 
exchange of MAC states information between neighboring BSs. 

R7 

ASN-GW-DP and 
ASN-GW-EP 

An optional set of control plane protocols for coordination between the 
two groups of functions identified in R6. 

R8 

BS and BS 

A set of control plane message flows and possibly bearer plane data 
flows between BSs to facilitate fast and seamless handovers. 
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Figure 27 provides details about the functions that pass through the Rl, R3, and R6 interfaces. The 
R2 interface is not indicated in the figure because it deals with services that pass between the SS node 
stations and the CSN. Interface R8 applies if, in the future, local mesh or ad hoc networking between SSs 
is implemented in an amendment to the standard. 
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Figure 27. — Network interfaces and functions. Acronyms are defined in Appendix A. 


Each airport location can be considered as a small enterprise with data communications occurring in 
the immediate vicinity of the airport property. Because of this, frequency planning for the Rl interface 
can consider only the BS sectors at a single airport unless other airports are within the radio LOS. Plans 
can be made to reuse the BS sector frequency within the C-band allocation within that small enterprise. 

Commercial IEEE 802.16-2009 hardware that is presently available can be procured with either a 
centralized ASN-GW or a distributed ASN-GW in which the gateway function is resident in each BS. 
The use of a centralized ASN-GW server versus a distributed function presently depends on the number 
of BSs in a network, with the distributed approach typically supporting up to six BSs. 

The functions at the R3 interface between ASN and CSN can be supported for relatively long 
distances over a secure IP network. One CSN will be able to support multiple small enterprises and could 
potentially support all airport surface communication networks across a national region. 

The number of multisector BS sites to be installed at an airport will depend on many factors including 
the physical size of the airport, the expected data load requirements, and factors that affect wireless signal 
propagation such as terrain and building shadowing and the need for high QoS. Network reliability and 
service availability will improve with at least two BS visible to each SS for the majority of the coverage 
area. This will provide reliable wireless linkage in the case that one of the available paths between an SS 
and BS is interrupted by an obstruction or hardware failure. Each airport will be somewhat unique in 
these factors and will require customized designs for the placement and quantity of BS sites to provide the 
needed QoS. 

Many options exist to implement a physical R3 interface between an ASN-GW and the CSN that is 
typically located at a central point and can be widely separated from the BSs. Making the R3 connection 
may be complicated by the limitations of existing IP network infrastructure in the airport environment. 
Positioning of the BS to achieve airport surface coverage may place it distant from an existing IP-based 
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network. A microwave backhaul link may be used to connect BSs and ASNs to the CSN to avoid the 
installation of cables. Another option is to use an SS to establish an in-band backhaul li nk to establish a 
limited-bandwidth connection. 

5.4 Physical System Architecture and Design Process 

The general network architecture was outlined in Section 5.3. Designing an AeroMACS network at 
an airport will require several tradeoffs to obtain the best performance, including 

• Location and number of BSs 

• Number of antenna sectors to employ per BS 

• Type of ba ckhaul system to support the ASN 

• Number of SS terminals that can be serviced by a BS 

Section 6.0 describes the system design process for new airport installations. 
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6.0 AeroMACS Design Considerations 

6.1 Airport AeroMACS Network Design Process 

An essential element in designing and deploying an AeroMACS network is a comprehensive RF 
design. An accurate design will ensure that the deployed wireless network provides the necessary 
coverage, capacity, and reliability, with minimal interference, that satisfies the service requirements. 
Although it is possible to gauge the performance of radio links through theoretical means, real-life 
deployments must take into account variables from the environment to achieve optimal performance and 
minimize coverage holes and RF co-channel interference. Figure 28 illustrates a top-level design flow for 
new AeroMACS network. 

The network design process begins with a physical site survey to gather information about the 
deployment location. A site survey provides an opportunity to validate any topography mapping 
information that may be available. It is also used to identify suitable installation locations for AeroMACS 
equipment. A site survey also provides input to the next three phases of the RF design process: coverage 
model, spectrum analysis, and capacity analysis. 

Before the design process can begin for an airport, general guidelines should be defined. Guidance on 
airport categorization, channelization methodology and power limitation recommendations are essential 
inputs to an AeroMACS network design. These are discussed in the following sections. 
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Figure 28. — AeroMACS network design process. 

6.2 Inputs to Network Design 

Channelization methodology and power limitations described below are considered important inputs 
that set the stage for the AeroMACS network design. 


6.2.1 Airport Categorization 

The purpose of this airport categorization task is twofold. First, creating a set of airport categories 
based on common airport characteristics and design objectives would facilitate initial AeroMACS 
architecture designs and enable budgetary projections. Though each AeroMACS will be implemented 
with its own unique characteristics, including the number of sites and channels required to provide 
adequate service, initial system designs and budgetary estimates often rely on typical parameters. 
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Second, the results are not intended to drive the final system design, but rather to offer high-level 
guidance to the potential AeroMACS technology and policy development sponsors and service providers. 
These may include the FAA Spectrum Office, various FAA Program Offices, airlines, airports, and 
others. 

6.2. 1.1 Methodology 

The flow chart in Figure 29 summarizes the categorization process as follows: 
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Figure 29. — Airport categorization process. 


Table 23 illustrates this relationship. 


TABLE 23.— MAPPING OF SYSTEM DESIGN TO AIRPORT CATEGORIZATION 


System design 

Airport 

categorization 

considerations 

Coverage 

Capacity 

Quality 

Type and volume of user and 
message traffic 

Coverage objectives may 
differ for different types of 
traffic 

The number of channels 
required will depend on the 
type and volume of traffic 

Unexpected increase in traffic 
volume may cause quality to 
degrade 

Airport topology 

More BSs will potentially be 
required to provide coverage 
in non-LOS conditions 

Non-LOS conditions may 
lead to smaller service areas 
of each of the BS with lower 
capacity requirements per BS 

If not managed, frequency 
reuse may lower the 
overall S/(I+N) thus 
causing quality 
degradation. 

Performance requirements 

Coverage objectives may 
differ to support different 
performance requirements 

Capacity objectives may 
differ to support different 
performance requirements. 

Quality objectives may differ 
to support different 
performance requirements 


Performance requirements were left out of the categorization process because of their dependency on 
services being provided. 

Thus, to meet the above categorization goals, the following characteristics were considered: 

• Type and volume of user traffic (i.e., potential service users) 
o How many users would be served 

o Type and volume of message traffic per user type 

• Airport topology 
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It should also be noted that categorization was found most relevant to mobile applications. 
Accommodation of fixed service infrastructure within an AeroMACS design would be program 
dependent following point to point system architecture considerations. As such, this task focuses on 
categorizing airports with respect to AeroMACS enabling mobile applications only. 

6.2. 1.2 Existing Airport Categorization by Type of Users 

Existing airport categorization schemes were reviewed to better understand the potential types of 
users per airport, their volume and distribution. Categories presented below are believed most relevant to 
the future AeroMACS operational deployment. 

6.2. 1.2.1 FAA Airport Categories 

The United States Code (USC) defines airports by airport activities, including 

• Commercial service (CS), primary and nonprimary 

• Cargo service 

• Reliever 

• General aviation airports 

Table 24 defines categories as follows: 


TABLE 24.— FAA AIRPORT CATEGORIZATION 


Airport classifications 

Hub ii ' b ’ type: 
percentage of annual 
passenger boardings 

Common name 

Commercial Service (CS): 

Publicly owned airports 
that have at least 2500 
passenger boardings 
each year and receive 
scheduled passenger service 

§47102(7) 

Primary: 

Have 
more than 
10,000 
passenger 
boardings 
each year 
§47102(11) 

Large 
> 1 

Large hub 

Medium 
>0.25, but <1 

Medium hub 

Small 

>0.05, but <0.25 

Small hub 

Non-hub 

More than 10,000, 
but less than 0.05 percent 

Non-hub primary 

Non-primary 

Non-hub 
At least 2,500 
and no more than 10,000 

Non-primary commercial 
service 

Non-primary (except commercial service) 

Not applicable 

Reliever 

§47102(18) 


a The FAA’s use of the tern “hub airport” is somewhat different than that of airlines, which use it to denote an airport 
with significant connecting traffic by one or more carriers. 

b The hub categories used by the FAA are defined in Section 40102 of Title 49 of the United States Code (USC) (2004). 


The remaining airports, while not specifically defined in Title 49 USC, are commonly described as 
General Aviation airports. This category also includes privately owned, public use airports that enplane 
2500 or more passengers annually and receive scheduled airline service. 
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Figure 30 presents the number of National Plan of Integrated Airport Systems (NPIAS) airports by 
type; Table 25 shows the percentage of enplanements, based aircraft, percentage of total development, 
and percentage of population within 20 miles of NPIAS airports. 



Figure 30. — Number of existing and proposed airports by ownership and use (January 2008) (Ref. 50). 


TABLE 25.— AIRPORT STATISTICS (REF. 50) 


Number of 
airports 

Airport type 

Percentage of 
2006 total 
enplanements 

Percentage of all 
based aircraft 3 

Percentage of 
NIP AS 2009-2013 
cost 

Percentage of 
population within 
20 m of airport 

30 

Large hub (HB) 
primary 

68.7 

0.9 

36 

26 

37 

Medium hub (MH) 
primary 

20.0 

2.6 

14 

18 

72 

Small Hub (SH) 
primary 

8.1 

4.3 

8 

14 

244 

Non-hub primary 

3.0 

10.9 

10 

20 

139 

Non-primary CS 

0.1 

2.4 

2 

3 

270 

Relievers 

0 

28.2 

7 

56 

2,564 

General aviation 

0 

40.8 

19 

69 

3,356 

Existing NPIAS 
airports 

99.9 

89.8 

100 

98 

16,459 

Low activity landing 
areas (Non-NPIAS) 

0.1 

10.2 

Not appropriate 

Not calculated 


“Based on active aircraft fleet of 221,942 aircraft in 2006. 


6.2. 1.2.2 COCR Airport Categorization 

The COCR (Ref. 11) applies airport categorization based on number of daily operations (number of 
aircraft serviced in a 24-hr period) per Air Traffic Services Unit (ATSU). Phase 1 is assumed to be 
completed around 2020. Daily operations for Phase 2 (beyond 2020) are derived from the Phase 1 values 
by assuming a 2.5 percent annual growth rate over a 10-year period. 
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COCR High Density (HD) and Low Density (LD) airports are defined in Table 26 as follows: 


TABLE 26.— DAILY OPERATIONS PER ATSU IN 
AIRPORT DOMAIN (APT) a 


Density 

Phase 1 

Phase 2 

High 

1800 

2304 

Low 

50 

64 


“APT domain is defined as an area 10 miles in diameter 
and up to -5000 ft consisting of the airport surface and 
immediate vicinity of the airport. At this time. 


AeroMACS is limited to communication on the airport 
surface. 

Additional data about the distribution of aircraft among airport air traffic control positions may also 
be useful when deciding on an AeroMACS site placement. Airport peak instantaneous aircraft counts 
(P1AC) defined in the COCR are in Table 27: 

TABLE 27.— PEAK INSTANTANEOUS AIRCRAFT 


COUNTS (PIAC) 


Airport position 

Phase 1 

Phase 2 j 

HD 

LD 

HD 

LD 

Clearance/ramp 

134 

4 

194 

7 

Ground 

48 

3 

70 

4 

Tower 

18 

5 

26 

8 

Total 

200 

12 

290 

19 


AeroMACS is proposed to not only enable communications with aircraft, but also to support various 
services requiring communication with other vehicles. COCR estimated airport surface vehicle PlACs are 
presented in Table 28 and Table 29. 


TABLE 28.— AIRPORT SURFACE VEHICLES 
PEAK COUNTS 


APT position 

Phase 1 

Phase 2 | 

HD 

LD 

HD 

LD 

Surface vehicles 

32 

4 

32 

8 


TABLE 29.— TYPES OF SURFACE VEHICLES FOR A 
HD AIRPORT 


Vehicle type 

Number of 
vehicles 

Buses 

12 

Dc-icing trucks 

2 

Snow trucks 

8 

Airport operations 

6 

Security and fire trucks 

4 

Total 

32 


Having nonaircraft data per type of airport would be very useful in estimating traffic type and volume 
for the related services. The numbers presented in the COCR appear to be low for most U.S. airport hubs. 
Additional up-to-date data should be collected at different airports and analyzed when available. 
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6.2. 1.2.3 Additional Categorization Options 

Additional airport categorization information was reviewed, such as 

• Airport traffic volume and ranking provided by the Airport Council International (AC I) 

(Ref. 51) 15 Information is available for U.S. and international airports for 

o Total passengers: arriving + departing passengers + direct transit passengers counted 
once 

o Total cargo: loaded + unloaded freight + mail in metric tonnes. Data includes transit 
freight total 

o Movements: landing + take off of an aircraft. 

• As defined by Title 14, Code of Federal Regulations (CFR) Part 139, Certification of 
Airports, airports are classified into four classes based on the type of air carrier 
operations served: (Ref. 71): Table 30 indicates the types of air carrier operations that 
each Part 139 airport class can serve. 


TABLE 30.— TYPES OF AIR CARRIER OPERATIONS FOR EACH AIRPORT CLASS 


Type of Air Carrier Operation 

Class I 

Class II 

Class III 

Class IV 

Scheduled Large Air Carrier Aircraft (30+ seats) 

X 




Unscheduled Large Air Carrier Aircraft (30+ seats) 

X 

X 


X 

Scheduled Small Air Carrier Aircraft (10-30 seats) 

X 

X 

X 



Airport classification by the type of traffic (as noted in Section 6.2. 1.2.1 above) is found 
more relevant to the proposed AeroMACS. 

• The Airport Reference Code (ARC) “is a coding system used to relate airport design criteria 
to the operational and physical characteristics of the airplanes intended to operate at the 
airport (Ref. 38).” Accordingly, the code consists of two components combining the aircraft 
approach category that relates to aircraft approach speed and the airplane design group that 
relates to airplane wingspan or tailheight. “Generally, runways standards are related to 
aircraft approach speed, airplane wingspan, and designated or planned approach visibility 
minimums. Taxiway and taxilane standards are related to airplane design group,” (Ref. 38). 

ARC categorization could be correlated with the other airport classifications. “Airports 
expected to accommodate single-engine airplanes normally fall into Airport Reference Code 
A-I or B-I. Airports serving larger general aviation and commuter-type planes are usually 
Airport Reference Code B-II or B-III. Small to medium-sized airports serving air carriers are 
usually Airport Reference Code C-III, while larger air carrier airports are usually Airport 
Reference Code D-VI or D-V” (Ref. 52). 

The ARC is found less applicable to AeroMACS than the USC system. AeroMACS is 
proposed to enable communication with the airport surface vehicles other than aircraft. 
Correlation of the ARC categories to vehicle volume and traffic would be too complex and 
not practical. 


15 Ranking only includes airports participating in the ACI annual stats collection. 
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6.2. 1.3 Categorization of Airports Based on Airport Topology 

Two often competing AeroMACS design objectives are (1) providing adequate RF coverage and 
(2) meeting the message traffic demand. System quality and end user perception of the service depend on 
both of these criteria. 

An initial effort was made to group airports with similar coverage and capacity design characteristics 
to determine the following system parameters: 

• Number of BS 

• Number of sectors per BS 16 

• Number of channels per sector 

• Total number of channels per airport 

This process is described in the following paragraphs. 

6.2. 1.3.1 Coverage Design 

Although coverage and capacity analyses and design are interrelated, typically coverage design is 
done first. AeroMACS coverage design will affect placement of the BSs as well their number and 
configuration (number of sectors per BS). 

The final coverage requirements will depend on the services to be enabled by the communications 
system. This analysis is service independent and might assume that both movement and nonmovement 
areas are supported. Only outdoor coverage is considered, excluding indoor areas, for example baggage 
areas and terminals that may be of potential interest to airlines. Indoor coverage needs to be considered 
and designed on a case-by-case basis. 

In general, coverage design will depend on the size of the airport (total area to be covered) and 
propagation environment. Propagation characteristics will vary between relatively open and dense areas. 
Dense areas can be defined as those with dense manmade obstructions and/or added complexity from the 
surrounding environmental characteristics (e.g., to account for terrain-challenged airports like Juneau, 
Alaska). Additionally, accounting for the orientation of the runways, apron structure shapes, and relative 
position of buildings on an airport surface allows categorizing airport environment based on different 
multipath propagation characteristics. 

Various CS airport layouts were analyzed by reviewing the FAA airport diagrams and aerial view 
photos. Multiple runway designs were identified, including parallel, crossing, V-shaped, and mixed. 
Terminal locations could be grouped by their location relative to runways, for example, “in-between,” 
“along one side,” or “in one comer.” Apron structure shapes included “snowflake,” “grid,” “star,” and 
others. Airports can be grouped based on these characteristics. Appendix D shows two examples of such 
characterization. 

It is possible to create a sample design using a propagation prediction tool for at least one airport in 
each of the above categories. This would provide a good estimate of the number of BSs needed to cover 
an airport to allow for a more accurate budget planning. Flowever, this approach is most accurate for 
systems consisting of a large number of sites. The number of AeroMACS BS sites to provide total surface 
coverage will likely vary between one and five per airport. Depending on the criticality and availability 
requirements of services provisioned at some airports, two BSs may be the lower limit. 

It is more practical to estimate the number of BSs based on test data from existing airport 
implementations. At this time, design data is available for one airport only: Cleveland Flopkins 
International (CLE). The ITT AeroMACS Prototype implemented in the NASA CLE CNS Test Bed 


1 6 A typical configuration for a busy airport may include three sectors per BS; six sectors per BS is a maximum 
practical configuration. 
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consists of 2 BSs. An estimated coverage radius for BS is 1.5 km. 17 The largest dimension of the CLE 
airport is about 3.5 km. 

When an average coverage radius is known, the number of BSs can then be estimated by dividing the 
total area to be covered by a typical coverage area provided by each of the BSs in the respective 
environment. This calculation assumes that BSs are located inside (i.e., not on the edge) of coverage areas 
and are evenly distributed throughout the service area. Placing BS at the edge of the desired coverage area 
may increase the total number of stations required. 

Omni or directional antennas will typically be deployed, with directional antennas likely used when 
sites are located at the edge of the service area. Sectored BSs with directional antennas may also be 
deployed to support higher capacity demand. 

The actual number of sites will vary depending on antenna location. If antennas are placed above the 
clutter (i.e., on the tallest building or on a tower), propagation would approach free-space characteristics 
and fewer sites may be needed. The number of BSs and the height above the surface and structures will be 
adjusted accordingly for each airport during the design phase. 

The number of BSs required will also depend on services provided and on other factors, such as the 
availability requirements. 

6.2.1.3.2 Capacity Design 

Both FAA and COCR categorization approaches reflect the potential traffic loading at an airport. 
Capacity planning, however, will largely depend on the services enabled by an AeroMACS. 

In general, system design can be either coverage or capacity driven as illustrated in Table 3 1 . 

TABLE 31.— CORRELATION BETWEEN COVERAGE AND CAPACITY DESIGN 



A design for a “complex” propagation environment airport will be coverage driven, i.e., the number 
of BSs needed to provide adequate coverage may be sufficient to support capacity demands. On the other 
hand, an “open” airport may require additional sites and/or additional sectors at a site to provide sufficient 
capacity when traffic volume is high. 

As capacity demand depends on the services being provided, channel requirements per BS would 
vary. Depending on the number of channels available to an airport, for the airports with high capacity 
demands, frequencies may need to be reused within an airport. A complex propagation environment 
allows for a closer frequency reuse without degrading quality. The total number of channels needed 
would also depend on the required frequency separation between different services. 

6.2. 1.4 Airport Categorization for AeroMACS 

In addition to coverage and capacity considerations, a business plan and cost of the proposed system 
will play an integral role in defining airport categories. 


17 Based on measurements for a 90 degrees sector, 100 mW power. The extend of coverage will differ for different 
coverage objectives (target QPSK) or if power is changed 
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General Aviation is the largest type of airport in the U.S. system. This statistic demonstrates that 
categories should not be limited to the CS Hubs, as this would exclude a significant number of airports 
that could potentially implement AeroMACS. 

Smaller airports may be interested in attracting new customers by offering additional services. A 
business plan will address if these services could be enabled by AeroMACS and offer sustainable 
financial benefits to an airport. 

Airports with less FAA presence may have different goals and resources than large hubs with 
extensive FAA presence. While FAA interest in an AeroMACS may be limited, opportunities for other 
sponsorships could open up. 

The level of existing communication services at an airport needs to be taken into account. A business 
plan will take under consideration whether the purpose of AeroMACS is to augment existing services or 
provide a green field solution. 

Airport categorization used by the FAA was found most pertinent to this task because it relates to 
both aspects of categorization — traffic type and volume — and geographical size. Table 32 below 
summarizes some of the guidelines to be applied to each group of airports using the FAA categories as a 
basis. 


TABLE 32.— PROPOSED AEROMACS AIRPORT CATEGORIES 


FAA Airport 
Category 

Potential AeroMACS Users 3 

Potential 

AeroMACS 

Architecture 

Comments and Guidelines 

Large Hub 

(LH) 

Primary 

FAA, airports, airlines, other 
service providers. 

Aircraft; other vehicles, 
including buses, de-icing, 
snow removal trucks, security 
and fire trucks, food service 
and baggage carts 

More than 2 
sectored BSs. 

Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air to ground 
communication as well as for the use of service 
vehicles on airport surface. 

LHs concentrate on airline passenger and freight 
operations and offer limited general aviation use. 

LHs have the greatest delays of all CS airports, which 
may lead to aircraft spending more time in the airport, 
potentially increasing capacity requirements to support 
air to ground communication in this domain. 

Medium 
Hub (MH) 
Primary 

FAA, airports, airlines, other 
service providers. 

Aircraft; other vehicles, 
including buses, de-icing, 
snow removal trucks, security 
and fire trucks, food service 
and baggage carts 

2 b sectored BSs 
Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air to ground 
communication as well as for the use of service 
vehicles on airport surface. 

Unlike LHs, MHs support a substantial amount of 
general aviation traffic in addition to carrier aviation. 
A business plan would target both categories, together 
or separately. 

Small Hub 
Primary 

FAA, airports, airlines, other 
service providers. 

Aircraft; other vehicles, 
including buses, de-icing, 
snow removal trucks, security 
and fire trucks, food service 
and baggage carts 

l-2 b BSs Number 
of channels per 
BS depending on 
applications 

AeroMACS may be used for air to ground 
communication as well as for the use of service 
vehicles on airport surface. 

Less than 25% of runway capacity is used by airline 
operations supporting many general aviation activities, 
making AeroMACS less attractive to airlines. Business 
plan may need to target AeroMACS for general 
aviation use. 

Non-hub 

Primary 

FAA, airports, other service 
providers. 

Aircraft; other vehicles, 
including buses, de-icing, 
snow removal trucks, security 
and fire trucks 

l-2 ba BSs 
Number of 
channels per BS 
depending on 
applications 

AeroMACS may be used for air to ground 
communication as well as for the use of service 
vehicles on airport surface. 

Heavily used by general aviation with enplaning less 
than 0.05 percent of all commercial passenger 
enplanements 


NASA/CR — 201 1-216997/VOL1 


81 




TABLE 32. — PROPOSED AEROMACS AIRPORT CATEGORIES 


FAA Airport 
Category 

Potential AeroMACS Users 3 

Potential 

AeroMACS 

Architecture 

Comments and Guidelines 

Non- 
primary CS 

Airports, FAA, other service 
providers. 

Aircraft; other vehicles, 
including buses, de-icing, 
snow removal trucks, security 
and fire trucks 

l b BS 

Number of 
channels per BS 
depending on 

Used mainly by general aviation potentially making 
AeroMACS less relevant to the FAA. 

Relievers 

Airports, FAA, other service 
providers. 

Aircraft; other vehicles, 
including buses, de-icing, 
snow removal trucks, security 
and fire trucks 

l b BS 

Number of 
channels per BS 
depending on 

Specialized airports providing pilots with attractive 
alternatives to using congested hubs. Have a 
significant number of based aircraft. 

AeroMACS may enable services to attract more users 
to a particular airport. 

General 

Aviation 

Airports, other service 
providers. 

Aircraft; 

Other vehicles, including 
buses, de-icing, snow removal 
trucks, security and fire trucks 

l b BS 

Number of 
channels per BS 
depending on 

Often located in rural areas. 

With limited existing communication infrastructure at 
some airports, AeroMACS may offer a green-field 
solution. 

AeroMACS may enable services to attract more users 
to a particular airport. 

Low 
Activity 
Landing 
Areas (Non- 
NPIAS) 

AeroMACS business case might not be supportable 


3 Further granularity can be achieved, if desired, by collecting and or obtaining statistics from the FAA or the airlines for 
different airport surface vehicles to quantify the potential users. 
b More BSs may be required to provide indoor coverage 


Guidelines presented in this section are based on system engineering judgment and the results of the 
tests performed within the AeroMACS Prototype. The fidelity of these recommendations will increase as 
new data becomes available, both policy and technical, related to practical implementations of 
AeroMACS. 

Results of the work being performed by RTCA to better define services to be supported by 
AeroMACS will affect many of the categorization considerations presented here. 

Additional research, for example, traffic analysis being conducted by Continental Airlines to estimate 
VoIP requirements and potential data rate needs based on current traffic volume (in Erlangs), may be 
useful in estimating the design parameters per category, such as the number of channels per BS. 

6.2.2 Channelization Methodology 

Channelization is the process of segmenting the available AMR(S) spectrum of 5091 to 5150 MHz, 
with possible additions, to allow multiple independent applications or services to operate simultaneously 
on the airport surface. Channelization will provide for channel bandwidths of 5 MHz and possibly 
10 MHz, as allowed by the AeroMACS profile. 

A channelization plan ensures that a large set of requirements are met with services potentially 
supplied by multiple service providers. A common global channelization methodology is needed to assure 
seamless interoperability with ground-based and A/G services. 

A channelization methodology is constrained by the potential for multiple categories of service and 
multiple service providers. Three distinct categories of service exist: air traffic control, airline, and airport 
operations. 
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Although a channelization methodology plan can be defined to a certain degree by analysis of 
technical factors, the final plan will be determined by FAA policy decisions regarding segregation of 
service traffic and service provider business plans. The discussion in Section 6. 2.2.2. 1 addresses the FAA 
policy of segregating the transport of Air Traffic Operations traffic. 

6.2.2.1 Channelization Study Overview 

The following sections provide an assessment of the factors and constraints that determine the 
channelization plan. The analysis followed the study map in Figure 3 1 . Each engineering study (ES) 
shown in the figure is discussed in a subsequent section of this report. 



5 MHz 10 MHz 

Channel Plan Channel Plan 


Figure 31 . — Channelization trade study map. 


6.2.2.2 Channel Bandwidth Studies 

6.2.2.2.1 Network Segmentation (ES1.1) 

The FAA has an interest in using AeroMACS to expand existing G/G fixed operational 
telecommunications capabilities and is also considering a number of A/G applications. Government and 
FAA policies could have a large impact on the architectures of AeroMACS networks that will support the 
Air Traffic Control (ATC), airline, and airport operations user domains. 

The FAA policy of not allowing use of FAA telecommunications resources for non-Govemmental 
functions, if implemented for AeroMACS, will prevent the use of a single integrated AeroMACS 
network that supports all three user domains. Instead, a separate and isolated network will be required 
for the support of FAA applications. Besides the obvious costs of duplicate hardware and maintenance 
to support multiple AeroMACS networks, such a policy will have an impact on the allocation of 
AM(R)S spectrum. 
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The FAA policy that requires network separation is FAA Order 1379.95 — WAN Connectivity 
Security (09/12/2006). This order requires FAA to maintain separation between FAA and non-FAA 
networks. 

The installation of two isolated networks will require that both be accommodated within the AM(R)S 
band. The use of 5-MFIz channels, for example, provides 10 to 11 channels within the 59 MHz AM(R)S 
band. The channelization plan could allocate five channels to a FAA network and five channels to a non- 
FAA network. 

The amount of signal power that is radiated at an airport is also impacted by the number of networks 
installed, which increases the potential for interference with co-users of the AM(R)S band. Dual networks 
will increase the total radiated power at an airport and thereby will increase the interference level. Co-user 
interference is discussed in Section 6.2.2. 4.2 

The decision whether to restrict use of an AeroMACS network to Government functions exclusively 
is a policy decision that currently has not been made at this date. Both a single network case for shared 
services and a dual-network case for isolated FAA services will be considered in this study. 

6.2.2.2.2 Efficient Use of Spectrum (ES1.2) 

Efficient use of the allocated AM(R)S band from 5091 to 5150 MHz will depend on the width of 
channel that is assigned to the BSs in the initial system design of the airport network. This section 
will examine the degree of efficiency for AM(R)S band utilization for 5- and 10-MHz channel 
bandwidths. 

All BSs within an AeroMACS network must be configured to operate at the same bandwidth. The 
59 MHz-wide AM(R)S band will support up to 1 1 channels with 5-MHz channel bandwidth. The actual 
allowable number of channels may be less than 1 1 because of in-band and band-edge guard bands as 
discussed in later sections. The algorithm for calculating the number of channels is Equation (1), where 
the integer value is taken of the spectrum bandwidth divided by the channel bandwidth. 

No. channels = integer[(5 150 - 5091) MHz /5 MHz] = 1 1 channels (1) 



Assignment of eleven 5-MHz channels is illustrated notionally in Figure 32 for the condition that no 
guard band is needed between channels. Channel center frequencies are placed on 5-MHz increments in 
frequency beginning at 5095 MHz. The uppermost channel is centered at 5145 MHz, which provides a 
2.5 MHz guard band at the upper AM(R)S band edge. The lowest channel, centered at 5095 MHz, 
provides a more limited guard band and may not be allowable as discussed in Section 6. 2.2.4. 1. The 
portion of unused AM(R)S band is analyzed in Table 33 for an 1 1 -channel assignment: 
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TABLE 33.— ANALYSIS OF AM(R)S BAND USAGE FOR 5-MHZ CHANNELS 


Lower band edge 

Calculation 



5095.0 MHz 
-2.5 MHz 
-5091.0 MHz 
= 1.5 MHz 

Lowest channel center frequency 
A channel bandwidth 
AM(R)S lower band edge 
Band-edge guard band 

Upper band edge 

5150.0 MHz 
-2.5 MHz 
-5145.0 MHz 
= 2.5 MHz 

AM(R)S upper band edge 
'A channel bandwidth 
Highest channel center frequency 
Band-edge guard band 


The use of eleven 5-MHz channels and a 2. 5-MHz band-edge guard bands provides full use of the 
AM(R)S band with some spill-over into the lower aviation band. If ten 5-MHz channels are used instead, 
4.0 MHz of the AM(R)S band will be unused. 

A notional channel assignment for 10 MHz channels is shown in Figure 33. The 59 MHz-wide 
AM(R)S band will support up to five channels when all channels have a 10 MHz bandwidth. The 
algorithm for calculating the number of channels is provided in Equation (2), where the integer value is 
taken of the spectrum bandwidth divided by the channel bandwidth. 

No. channels = integer[(5150 - 5091) MHz 10 MHz] = 5 channels (2) 



Figure 33. — Notional channel allocation for 10-MHz bandwidth. 


An analysis of the use of 10-MHz channels in the AM(R)S band is given in Table 34. 


TABLE 34.— ANALYSIS OF AM(R)S BAND USAGE FOR 10-MHZ CHANNELS 


Lower band edge 

Calculation 



5100.0 MHz 
-5.0 MHz 
-5091.0 MHz 
= 4.0 MHz 

Lowest channel center frequency 
A channel bandwidth 
AM(R)S lower band edge 
Band-edge guard band 

Upper band edge 

5150.0 MHz 
-5.0 MHz 
-5140.0 MHz 
= 5.0 MHz 

AM(R)S upper band edge 
A channel bandwidth 
Highest channel center frequency 
Band-edge guard band 


The use of five 10-MHz channels and a 2. 5-MHz band-edge guard bands effectively means that 4 MHz 
of the AM(R)S band is unused for information channels or band-edge guard bands. Comparing 3.5 MHz of 
unused AM(R)S band for 10-MHz channels to full use for eleven for 5 MHz channels leads to the 
conclusion that 10 MHz channels provides a less-efficient use of the 59-MFIz AM(R)S band allocation. 
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6.2.2.23 Multiple Service Providers (ES1.3) 

The WiMAX Network Reference Architecture provides a flexible framework that can accommodate a 
variety of AeroMACS deployment scenarios. Network architectures for single or multiple network access 
providers (NAPs) and single or multiple network service providers (NSPs) are accommodated in the framework. 

Relationships between NAPs and NSPs and the assignment of network functions at a single airport 
are illustrated in Figure 34. Multiple NAPs could be implemented in an AeroMACS network for the 
purpose of isolating types of traffic. For example, one NAP could be implemented to handle critical ATS 
data with a second NAP handling less critical traffic for AOC and airport operations. Base station 
hardware, ASN gateway server hardware and software, and spectrum allocations are required to 
implement each NAP. Spectrum bandwidth limitations make greater than two NAP installations per 
airport impractical for multisector BS installations. 

Flaving multiple NSPs at an airport is more practical to implement in term of resources because 
instantiation of a NSP requires a CSN server and software and can be served by a single NAP. NSPs can be 
responsible for differing applications. However, the multiple NSPs will need to respond to overall policies 
for service provisions and QoS assignments. These policies would presumably be established by FAA. 



Figure 34. — Network access provider (NAP) and network service provider 
(NSP) network sharing. 


6.2.2.3 Channel Center Frequency Grid (ES2.1) 

Two significant factors will be analyzed for their effect on channel center frequency assignments. 
First, the center frequency step size will be studied because a small step size could cause large acquisition 
times when a SS first enters a network as discussed in Section 6.2.2.3.I. Secondly, the use of a guard- 
band between channels, if needed, will shift channel center frequencies as discussed in Section 6.2. 2. 3. 2. 

6.2.2.3.1 Impact on Initial Network Acquisition Time (ES2.2) 

The number of allocated channel center frequencies will have an effect on the time required for a SS 
to initially join a new network. Acquisition time is important, for example, when an aircraft lands at an 
airport and begins the authentication process to join the local AeroMACS network. The process of initial 
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network discovery and authentication and the impact of the channel center frequency planning on 
acquisition time will be examined in this section. The process of joining a network in which a SS must 
discover the local services and be authenticated and authorized for service is illustrated in Figure 35 
(Ref. 75). The process begins with an initial frequency scan to discover the base station channels that are 
available. Because the center frequency assignments of base station channels will vary by airport, a SS 
will begin by scanning through the AM(R)S band to detect BS channel assignments. 


Frequency scan process for BS discovery 
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Figure 35. — IEEE 802.16 channel acquisition and initial ranging. 


The IEEE 802.16-2009 standard defines that a SS will maintain a preprogrammed table of channel 
center frequencies to scan during this initial discovery. The method of using the scan table is not fully 
defined in the standard, but is left to the equipment manufacturer to design the scan method according to 
market needs. The algorithm for this scan is therefore dependent on manufacturer's choices. 

The AeroMACS hardware implemented in the NASA-Glenn AeroMACS Prototype implements a 
scan algorithm that is hard-programmed within a COTS chipset. This algorithm implements the following 
steps: 

(1) When a frequency scan round begins, the SS performs power measurements on each frequency 
that is pre-configured in the SS scan table. This process takes 10ms per frequency. 

(2) If any energy is detected, the SS tries to acquire a MAP within the downli nk frame in 3 
frequency offsets per each center frequency (F, F-10.9 KHz, F+10.9 KHz). This process takes at 
least 530 ms per each frequency offset. 

(3) If a valid BTS ID is detected, the SS will attempt access into the network at two frequency 
offsets (best 2 out of the above 3 spots). Each requires up to an additional 1300 ms to get 
establish a link (depending on the preamble samples it needs to collect). 

As a conclusion, if the frequency is free (there is energy but not a valid BTS active) the scanning 
process takes 10 + 3><530 = 1.6 sec, and if a BTS has been detected on that frequency the process takes 
10 + 3x530 + 2x1300 = 4.2 sec. 
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The IEEE 802.16-2009 standard requires that the SS be capable of frequency steps in 250-kHz 
increments. The step size during acquisition scan is determined by the frequency scan table that is 
programmed in the SS at the time of operational deployment. 

Table 35 illustrates the impact of frequency step size, as implemented in the SS frequency scan table, 
for two step sizes. The 250-kHz step size represents the smallest step size supported by the standard. The 
5-MHz step size, representing a large step, corresponds with the BS step size for COTS equipment that is 
available for the 5-GHz WirelessHUMAN market. The initial acquisition scan time is calculated for the 
algorithm described above for both step sizes. The frequency scan step size of 250 kHz results in a 
nominal scan time of 6 minutes, 18 seconds. A step size of 5 MHz allows the scan to nominally complete 
in 18 seconds. This illustrates the importance of a well planned frequency scan table. 

For the reasons discussed, a step size of 5 MHz is recommended for AeroMACS to minimize the time 
for an aircraft SS unit to access a network upon arrival at an airport. A 5-MHz step size also maintains 
compatibility with the COTS market segment. A standardized frequency scan table is needed for global 
deployment to minimize the time for a mobile SS to acquire a new network. 


TABLE 35.— ANALYSIS OF AQUISITION TIME 


Fstep = 250 kHz Analysis 

Fstep = 5 MHz Analysis 

# steps = int {(5 1 50 - 5091)MHz/250 kHz[ 
= 236 steps 

# steps = int {(5 150 - 5091)MHz/5 MHz[ 
= 1 1 steps 

Acquisition scan time = 236 * 1 .6 s = 378 s 
=> 6 minutes, 18 s 

Acquisition scan time = ll*1.6s=18s 


6.2.2.3.2 In-band Frequency Guard Band 

In-band guard bands are frequency separations between edges of channels that are used to reduce 
cross-channel interference. Each 5 or 10 MHz AeroMACS channel will have transmitter energy that falls 
outside of the intended channel. This out-of-channel energy can cause interference in adjacent channels. 
Separating the channels with guard bands will reduce the level of cross-channel interference and in turn 
will lower packet error rates. 

The use of in-band guard bands is undesirable for a number of reasons. First, their use will reduce the 
number of channels that can be allocated within the 59 MHz of AM(R)S spectrum. Second, the minimum 
guard bandwidth is 5-MHz for a system that is compliant with WirelessHUMAN standard for 5-GHz 
unlicensed bands. In addition, several methods to mitigate cross-channel interference are already built 
into the IEEE 802. 16 standard and can be implemented with proper system design. 

The standard implements cross-channel interference reduction through use of subcarrier suppression 
at channel edges. This edge suppression forms a guard band without purposely allocating an additional 
guard-band separation between channels. This section investigates the need for in-band guard band 
allocations that are in addition to what is implemented in the standard. 

The overlap of adjacent channels is illustrated in Figure 36. The amount of energy that is radiated 
outside of a channel is defined by the spectral mask. This radiated energy will cause interference with 
adjacent channels if not adequately controlled. 
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Figure 36. — Adjacent channel spectrum overlap. 

The spectral mask recommended for AeroMACS is taken from Federal Communications Commission 
(FCC) part 47 paragraph 90.210 (Ref. 54). The AeroMACS spectrum mask requirement is based on 
“mask m” from paragraph 90.210 for all power levels authorized for the AeroMACS service. The power 
spectral density of the emissions must be attenuated below the output power of the transmitter as follows: 

( 1 ) On any frequency removed from the assigned frequency between 0 to 45% of the authorized 
bandwidth (BW): 0 dB. 

(2) On any frequency removed from the assigned frequency between 45 to 50% of the authorized 
bandwidth: 568 log (%of (BW)/45) dB. 

(3) On any frequency removed from the assigned frequency between 50 to 55% of the authorized 
bandwidth: 26 + 145 log (% of BW/50) dB. 

(4) On any frequency removed from the assigned frequency between 55 to 100% of the authorized 
bandwidth: 32 + 31 log (% of (BW)/55) dB. 

(5) On any frequency removed from the assigned frequency between 100 to 150% of the authorized 
bandwidth: 40 + 57 log (% of (BW)/100) dB. 

(6) On any frequency removed from the assigned frequency between above 150% of the authorized 
bandwidth: 50 dB or 55 + 10 log (P) dB, whichever is the lesser attenuation. 

(7) The zero dB reference is measured relative to the highest average power of the fundamental 
emission measured across the designated channel bandwidth using a resolution bandwidth of at 
least one percent of the occupied bandwidth of the fundamental emission and a video bandwidth 
of 30 kFIz. The power spectral density is the power measured within the resolution bandwidth of 
the measurement device divided by the resolution bandwidth of the measurement device. 
Emission levels are also based on the use of measurement instrumentation employing a resolution 
bandwidth of at least one percent of the occupied bandwidth. 
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Figure 37. — FCC part 47 paragraph 90.210 Mask m. 

Mask m attenuation is plotted graphically as percentage of bandwidth in Figure 37. 

The amount of adjacent channel protection built into the IEEE 802.16-2009 standard on which 
AeroMACS is based can be analyzed using this spectral mask and properties of the AeroMACS channel 
defined by the standard. The standard requires that a certain number of subcarriers in the waveform be 
suppressed at the band edges. The number of suppressed carriers and their equivalent bandwidth are listed 
in Table 36 for 5- and 10-MFIz channel bandwidths. 


TABLE 36.— ANALYSIS OF AEROMACS CHANNEL PROPERTIES 


Channel 

Number of lower 

Number of upper 

Allocated guard 

Allocated guard 

Channel-to-channel 

bandwidth 

subcarriers 

subcarriers 

band, lower, 

band, upper, 

total guard band, 


suppressed 

suppressed 

MHz 

MHz 

MHz 

5 MHz 

46 

45 

0.503 

0.492 

0.996 

10 MHz 

92 

91 

1.006 

0.996 

2.002 


The built-in guard band defined in the standard is 1 0 percent of the channel bandwidth at the upper 
and lower ends of each channel. The adjacent channel signal is suppressed by the spectrum mask at the 
closest subcarrier of the adjacent channel as follows: 

(1) First adjacent carrier is removed from lower channel center frequency by 60 percent of channel 
bandwidth. 

(2) First adjacent carrier falls in the range of 55 to 100 percent of the channel bandwidth 

(3) Mask attenuation = 32 + 31 log (% of (BW)/55) dB = 33.2 dB 
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The spectral mask therefore provides greater than 32 dB of attenuation at the first subcarrier of an 
adjacent channel. This is the minimum attenuation that is expected for two reasons. First, the mask 
continues to increase attenuation as the frequency of separation increases. Secondly, a sectorized base 
station will increase attenuation for an adjacent channel because of pattern roll-off as illustrated in 
Figure 38. A SS at position 1 that is associated with BS sector 1 and transmitting at frequency FI, for 
example, will cause reduced adjacent-channel interference with BS sector 2 at frequency F2 because of 
pattern roll-off. Position 2 is a worst-case location because the adjacent sector antenna gain is its highest 
before the SS would be handed over to the adjacent sector. 

2-Sector Base Station 



for Adjacent-Channel Interference 

Figure 38. — Base station sector effects on adjacent channel interference. 

The carrier-to-interference and noise (C1NR) ratio required to support the highest modulation rate of 
QAM-64, FEC 3/4, is listed as 31.45 dB in Table 308 of the IEEE 802.16-2009 standard. Spectral mask 
attenuation of 32 dB at the first carrier of adjacent channels marginally support this requirement with no 
additional guard-band spacing added between channels. 

The utility of in-band guard bands was tested in the NASA-Glenn AeroMACS Prototype. Results of 
this evaluation are in Section 3.2.3 of Volume 11 of this report. 
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6.2.2.4 


Band Plan Studies 


6.2.2.4.1 Band-Edge Guard Band (ES3.1, ES4.1) 

RF emissions that spill outside of a channel bandwidth have the potential to cause interference to 
non-AeroMACS users and to services in frequency bands that are adjacent to the AM(R)S spectrum. A 
spectral mask describes the channel-edge roll-off characteristics of a transmitter and can be used to assess 
potential out-of-band interference issues. 

All wireless local area networks (LANs) operate in the United States as part of the unlicensed 
National Information Infrastructure devices under FCC Part 15, Subpart E. Most of these devices require 
that emissions outside of the authorized band not exceed -27 dBm/MFIz 

A 100 mW AeroMACS transmitter set to 5 MFIz channel bandwidth, for example, has a radiated power 
of 20 dBm across 5 MFIz, which is equivalent to 1 3 dBm/MHz The required out-of-band attenuation to be 
controlled by the spectrum mask is therefore >40 dB in order to not exceed-27 dBm/MFIz. Similarly, the 
spectrum mask attenuation must be >37 dB for 10 MHz channel bandwidth. 

The spectral mask recommended for use with AeroMACS conforms to the requirements of FCC part 
47 paragraph 90.210. The AeroMACS spectrum mask requirement is based upon mask m from paragraph 
90.210 as described in Section 6. 2.2. 3. 2. 

Mask m provides an attenuation of 26 dB at 50 percent of channel bandwidth, which corresponds 
with the edge of a channel. Since >40 dB of attenuation is required in order to not exceed -27 dBm/MHz 
for 5 MHz channel bandwidth, an additional band-edge guard band will be required. Attenuation >40 dB 
is provided by mask m at 100 percent of bandwidth. The channel edge must therefore be placed at least 
2.5 MHz away from the AM(R)S band edge for 5 MHz channels. 

Band-edge guard band allocations will be needed for 10 MHz channel width since >37 dB of 
attenuation is required in order to not exceed -27 dBm/MHz. Mask m provides 37 dB of attenuation at 
80 percent of bandwidth. Therefore, the channel edge must be placed at least 3.0 MHz away from the 
AM(R)S band edge for 10 MHz channels. 

Mask m is illustrated in Figure 39 for a 5-MHz channel bandwidth. The 40-dB attenuation point is 
marked at 5 MHz above the channel center frequency and 2.5 MHz above the channel edge. The out-of- 
band emissions limit will be met with mask m when the channel center frequency is placed at least 5 MHz 
away from a band edge and the transmitter power is limited to 100 mW or less. 



Figure 39. — FCC part 47 paragraph 90.210 mask m for 5-MFIz channel bandwidth. 
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Mask m is illustrated in Figure 40 for a 10-MHz channel bandwidth. 37 dB of attenuation is marked 
at 8 MHz above the channel center frequency and 3 MHz above the channel edge. The out-of-band 
emissions limit will be met with mask m when the channel center frequency is placed at least 8 MHz 
away from a band edge, and the transmitter power is limited to 100 mW or less. 



Frequency, MHz 


Figure 40. — FCC part 47 paragraph 90.21 0 mask m for 1 0-MHz channel bandwidth. 


6.2.2A.2 Co-user Interference 

AeroMACS is a co-user in the AM(R)S band with other services. Of primary concern is potential 
interference from AeroMACS into the Mobile-Satellite Service (MSS) feeder uplinks that currently exist 
in the AM(R)S band. Practical limits on AeroMACS transmissions must exist so that the threshold of 
interference into MSS is not exceeded. Establishment of practical limits is discussed as part of power 
limitation recommendations in Section 6.2.3. The impact of channelization methodology on co-user 
interference will be introduced in this section. A channelization methodology for AeroMACS in the 
AM(R)S band will impact MSS interference because of the limited bandwidth of MSS receiver passbands 
relative to AeroMACS channel bandwidth. 

Interference into MSS receivers results as a composite of all AeroMACS stations that are within view 
of an orbiting MSS satellite. Because of the orbital height and broad pattern of receive antennas, an MSS 
receiver will have visibility to transmissions from all CONUSE AeroMACS stations for periods within 
their orbit. It is therefore important that AeroMACS transmissions are distributed evenly across the 
AM(R)S band when considering transmissions from many airports. A corollary requirement is that no 
“hot spots” be formed within the AM(R)S band by establishment of a preferred frequency for BSs. 
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6.2.2.5 Channelization Methodology Summary 

Conclusions and recommendations from individual studies within this task are summarized in 
Table 37. 


TABLE 37.— CHANNELIZATION STUDY RESULTS SUMMARY 


Study Task 

Study 

Number 

Constraints 

Conclusions and 
Recommendations 

Network segmentation 
for ATC traffic isolation 

ESI .1 

• Two isolated networks per airport may be 
required by policy 

• Dual networks make 10-MHz channel 
bandwidth impractical for multiple sectorized 
BSs 

• Dual networks reduces number of airports 
within co-user interference limits 

This is a policy-driven decision 
within the constraints stated. 

Efficient use of 
spectrum 

ESI. 2 

• Band-edge guard bands are needed to limit out- 
of-band emissions 

• 10-MHz channel bandwidth causes wasted 
spectrum at AM(R)S band edges beyond that 
needed for band-edge guard bands 

5-MHz channels provide greater 
spectrum efficiency. 

Multiple access and 
service providers 

ESI. 3 

• Number of Access Service Providers is limited 
by spectrum allocation 

Implement single access provider 
with an option for multiple service 
providers. 

Effect on initial 
acquisition time 

ES2.1 

• SS/MS units search for BS center frequencies 
during initial network acquisition 

• Significant acquisition delays are multiplied by 
the number of search frequencies required 

• Search algorithm will vary by hardware 
manufacturer and can be customized 

• BS channel center frequency options must be 
standardized for global interoperability of 
SS/MS 

Choose wide frequency spacing 
for BS channel center frequencies 
options. A grid based on 5-MHz 
increments specified in 
WirelessHUMAN standard is 
preferred for lowest acquisition 
time. 

In-band frequency guard 
band 

ES2.2 

• Adjacent channel interference was found to 
have insignificant effect on link performance 
when evaluated in the NASA-Glenn Test Bed. 

• Use reduces efficient use of spectrum 

In-band frequency guard band 
allocations are not required. 

Band-edge guard band 

ES3.1, 

ES4.1 

• Spectral mask chosen for AeroMACS requires 
band-edge guard bands to prevent excessive out 
of band emissions 

• 5-MHz channel width requires a 2.5-MHz 
guard- band allocation 

• 10-MHz channel width requires a 3-MHz 
guard-band allocation 

Band-edge guard band allocations 
are required. 

Co-user interference 

ES3.2, 

ES4.2 

• Co-user interference is minimized with efficient 
use of AM(R)S spectrum 

• Interference is increased when dual isolated 
networks per airport are required 

Use single share-services network 
with 5-MHz channel bandwidth. 


6.2.3 Power Limitation Considerations 

Multiple BS sectors, each called a BTS, will typically be required for wide-area coverage across the 
airport surface of medium and large airports. A number of factors will be used to determine the 
transmitted power of each BTS, but two overriding factors will “bracket” the allowable power range. 
First, the transmit power must provide adequate received signal strength information (RSS1) and C1NR 
signal levels at the SS receiver that will support the intended link coverage. The need to support a 
coverage area sets the lower bound for transmit power. 

The second factor that brackets transmit power, this time on the high side, is the potential to interfere 
with co-users of the AM(R)S band. Of immediate interest is interference from AeroMACS in to the 
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Mobile-Satellite Service (MSS) feeder uplinks that currently exist in the AM(R)S band. Practical power 
limits on AeroMACS transmissions must exist so that the threshold of interference into MSS is not 
exceeded. 

A MITRE study that examined potential co-user interference from AeroMACS will be used for a 
reference system for airport surface coverage and Tx power limitations (Ref. 55). A NASA study 
supported and validated the conclusions of the MITRE report (Ref. 56). Values from the MITRE study 
will be compared to test results using the NASA-Glenn AeroMACS Prototype. 

6.2.3. 1 Coverage Requirement 

The MITRE study based its airport surface coverage and transmit power requirements analysis on a 
typical airport requiring three BSs, each BS having three BTS sectors, and each BTS sector having a 
1.73 km coverage radius. The configuration used in the MITRE study provides coverage for an airport of 
a radius of 3 km. 

Results from mobile drive tests on runway 24L/6R and airport peripheral roads can be used for a 
preliminary projection of the transmit power required to provide a 1.73 km coverage radius. The drive 
tests and results analysis are summarized in Section 3.2.2. 3 of Volume 11. 

Drive tests on runway 24L/6R resulted in a minimum AeroMACS throughput rate of 3 Mbps for a 
maximum range of 5620 ft (1.71 km) for the conditions of the NASA Glenn “AeroMACS Prototype” 
column of Table 38. The maximum link range of this drive test closely supports the maximum range used 
by MITRE in their analysis. This also supports the sector coverage radius of 1.5 km that was assumed for 
the NASA CLE CNS Test Bed in the Coverage Design (Section 6.2.2. 1) in this report volume. 


TABLE 38.— COVERAGE AND Tx POWER PARAMETER COMPARISON 


Parameter 

AeroMACS 

prototype 

MITRE study 

Delta dB 

Channel bandwidth 

5 MHz 

10 MHz 

3 

Power per transmitter 

100 mW 

170 mW 

.... 

Antenna mode 

MIMO 

SISO 

.... 

Total Tx power per BTS sector 

200 mW 

170 mW 

0.7 

BTS antenna gain (maximum) 

15 dBi 

15 dBi 

0 

Number of overlapping BTS stations 

226 a 

497 

-3.4 



Difference, dB 

0.4 


a 226 is the number of BTS stations that overlap in channel frequency for 497 airports distributed 
across CONUS based on 5 channels in use at each airport and 1 1 5-MHz channels available. The 
NASA CLE CNS Test Bed is presently installed with 5 BTS sectors so is limited to 5 frequency 
channels. 

AeroMACS mobile link performance exceeded 1.5 km range in the airport peripheral road test of 
December 16th that is described in Section 3.2. 2. 3 of Volume II. The ARV SS was connected with BTS 
1-1 sector while travelling on the airport peripheral road around the end of runway 24L/6R. A traffic 
throughput rate of 6 Mbps was maintained for the duration of this drive test which had a maximum range 
to BTS 1-1 of 2.15 km. This result provides additional affirmation for adequate airport surface coverage 
using 1 00 mW BTS transmit power when MIMO antenna configurations are implemented. 

6.2.3.2 Co-user Interference Limitation 

Conditions for the MITRE interference study are listed under the MITRE Study column of Table 38. 
The impact of parameter differences between those used in the AeroMACS Prototype for the drive test 
and those in the MITRE study are summarized as follows: 
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• Channel bandwidth — The MITRE study is based on use of 1 0-MHz channel bandwidths, while 
the AeroMACS Prototype was set to 5-MHz channel bandwidths for the runway drive test. Thi s 
causes a 3 dB increase in radiated power per Hertz because a set transmit power level is spread 
over half of the bandwidth for in the AeroMACS Prototype. A difference of 3 dB is listed in the 
“Delta dB” column of Table 38. 

• Power per transmitter — The MITRE study limited the total transmitted power level per BTS to 
170 mW (22.3 dBm). Each diversity channel used in the AeroMACS Prototype was set to 100 mW 
(20 dBm) during the runway drive test, which is the current limitation of the installed hardware. 

• Antenna Mode — The MITRE study included only one transmit channel per BTS sector as would 
be the case in the nondiversity S1SO antenna mode. The AeroMACS Prototype uses two 
transmitters per BTS sector for diversity transmission in M1MO antenna mode. 

• Total Tx power per BTS sector — Total transmitter power per BTS sector is twice that of a single 
transmitter in the AeroMACS Prototype because of the 2-channel diversity antenna mode. The 
MITRE study is therefore based on a total transmitted power of 170 mW while the AeroMACS 
Prototype radiates 200 mW per BTS sector. A difference of 0.7 dB is listed in the Delta dB 
column of Table 38 to account for this difference. 

• BTS antenna gain (maximum) — The BTS sector antenna gain of 15 dBi used in the MITRE study 
is the same as is used in the AeroMACS Prototype installed hardware. 

• Number of overlapping BTS stations — The MITRE study is based on AeroMACS installation at 
497 towered airports 18 in the continental United States and 1 0-MHz channel bandwidths. As 
determined in Section 6.2. 2.2, it is possible to fit five 10-MHz channels in the 59-MHz AM(R)S 
allocation. The same the 59 MHz AM(R)S allocation will support up to 11 channels of 5 MHz 
width. A “Delta dB” factor of 10><log(5/l 1) is listed because a smaller fraction of the 59 MHz 
AM(R)S allocation is occupied when five 5-MHz channels are implemented. 

The net difference in interference level to co-users of the AM(R)S band is 0.4 dB for the AeroMACS 
Prototype as implemented compared to the conditions of the MITRE study. Use of 5-MHz channels will 
follow Scenario C of the study, which is one transmitter per frequency channel at an airport. A conclusion 
stated in the MITRE study is that all three scenarios studied resulted in the maximum aggregate receive 
power at the satellite receiver is below the interference threshold. The margin available for Scenario C is 
not stated. Further study is required to determine whether the 0.4 dB higher transmitted power of the 
AeroMACS Prototype configuration will exceed the interference threshold. Transmit power could be 
reduced to levels used in the MITRE study if needed, resulting in a traffic throughput rate reduction 
compared to the runway drive test results. 

It should also be noted that the runway drive test results used in this comparison to MITRE 
interference study are for a relatively benign link condition of line-of-site between BS and SS without a 
complex multipath environment. More study is required to assess AeroMACS performance in non-line- 
of-sight, high-multipath conditions that will exist in highly congested terminal areas. 

6.2.4 Recommendations for Power Limitations 

A comparison has been completed between the operating parameters used in the NASA-Glenn 
AeroMACS Prototype for runway drive tests compared to the conditions used in the MITRE study of 
co-user interference. Conditions for level of interference to co-users were approximately within 0.4 dB 
although many parameters differ, such as channel bandwidth, antenna mode, and transmitter power 
output. The runway drive test performance that maintained at least 3 Mbps throughput rate to a range of 
1.7 km provides an initial assessment supporting excellent performance while operating within 
interference constraints. Additional checks under more severe propagation conditions are required in 
order to gain confidence that viable links can be supported. 


18 The towered airport correspond with FAA Airport Categories of “Large Hub (LH) Primary” through “Relievers” 
listed in Table 32. 
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6.3 Coverage Model 

The coverage model requires a map of the site along with coordinates of potential locations for BSs 
and SSs. The coverage model must account for the impact of the environment on the RF transmissions, 
including the effects of the topography, physical obstructions, and foliage. These effects introduce 
propagation delays that have been cataloged in reference models. In addition, clutter models or 
obstruction densities are also modeled in this phase. Clutter models represent the density of obstructions 
in the deployment site. Typical options include rural, urban, and suburban clutter models. An airport 
surface with its relatively open runways and taxi areas and congested terminal areas will be a combination 
of the three models. 

In addition to considering site topology and propagation delays, general parameters of the AeroMACS 
solution must be identified. Notable parameters include BS and SS transmit/receive power, antenna gains, 
feeder losses, BS and SS heights, and orthogonal-ffequency-division multiple access (OFDMA) radio- 
access-related parameters. In addition, the following are the relevant system design parameters: 

• Radio access method 

• Fade margin 

• Antenna sensitivity and diversity 

• Cochannel interference margin 

• Duplex mode 

• Modulation 

• Error correction 

• UL/DL ratios and throughput 

• BS and SS noise figure 

• Maximum output/input power 

Finally, a link budget must be calculated that specifies the maximum path loss between each BS and 
SS. Receiver sensitivity of the equipment for supported modulation schemes can be obtained from the BS 
and SS vendor data sheets. Characteristics of the BS and SS and information about the placement and 
types of antennas are used to generate an accurate coverage map. 

6.4 Spectrum Analysis 

The spectrum analysis phase of radio planning involves analyzing a potential site for interference to 
the proposed AeroMACS. Interferers can include fundamental emissions plus transmitter harmonics and 
intermodulation emissions. An analysis involves measuring the maximum transmitter signal levels to 
determine how much energy is present in the surveyed RF band. The spectrum analysis can be conducted 
at ground level, but it is typically conducted from elevated locations including rooftops and tower sites at 
least 50 ft high. 

6.5 Capacity Analysis 

The capacity analysis involves calculating how much traffic can be supported given the UL/DL ratio 
and the anticipated traffic patterns with the specified bandwidth and modulation scheme. The parameters 
used for capacity calculations include 

• Time-division duplexing (TDD) UL/DL ratio 

• Mode of operation 

• Channel bandwidth 

• Subcarrier allocation scheme 

• Guard ratio timing 
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The theoretical physical layer (PHY) throughput per modulation scheme can be calculated using the 
following formula (Ref. 47): 


R b = R s MC/R, 


( 3 ) 


where 

M modulation gain (2 for quadrature phase-shift keying (QPSK), 4 for 16-quadrature amplitude 
modulation (QAM), and 6 for 64-QAM) 

C coding rate (1/2, 3/4, 2/3, or 5/6) 

R r repetition rate (1,2, 4, or 6) 

R h bit rate 

R s symbol rate 

Equation (3) accounts for the pilot overhead but does not account for the signaling overhead, which 
depends on the number of active connections and the service types used. Studies have found that 
signaling overhead may vary from 4 to 1 0 percent of PHY throughput. Estimating capacity using RF 
design tools takes into consideration the impact of multiple input, multiple output (M1MO) antenna 
schemas to enhance coverage and/or capacity. 

Although theoretical and software-based tools provide a baseline for determining the capacity of an 
AeroMACS network, it will be necessary to make minor adjustments once the network has been 
implemented. Such optimization involves selecting appropriate network parameters that will support the 
QoS requirements. A test drive through the deployed network is the final step for collecting network data 
for analysis and optimization. 

6.6 Design Tradeoffs for an AeroMACS Network 

Table 39 lists many parameters that must be included in design tradeoffs for an AeroMACS network. 
The “Design category” column defines broad parameter categories, and the “Parameters” column lists in 
detail the parameters that interrelate during the design process. The “Considerations and system design 
parameters” column gives recommendations for the system tradeoffs, many of which are unique to the 
airport surface environment. 


TABLE 39.— AEROMACS NETWORK DESIGN CONSIDERATIONS 


Design 

category 

Parameters 

Considerations and system design parameters 

Base station 

Mounting placement 

Total network data throughput 

(BS) 


Line-of-sight/non-line-of-sight (LOS/NLOS) coverage area 
Low-level blockage avoidance 


Number of BS and base 

BS throughput 


transceiver station (BTS) sectors 

Channel bandwidth and available spectrum 


Multiple input, multiple output 

BS cell radius requirements 


(MIMO) order 

Transmitter (Tx) power 

Near-line-of-site and blocked-path performance 
Multipath mitigation 
Mobility dropouts 

Interference to out-of-band users will be decreased by MIMO because total 
radiated power can be reduced. 


Antenna polarization 

Cross-polarized versus spatially separated antennas 
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TABLE 39.— AEROMACS NETWORK DESIGN CONSIDERATIONS 


Design 

category 

Parameters 

Considerations and system design parameters 


Maximum cell range 

Number and placement of BSs 

BTS sector and subscriber station (SS) Tx power 

Controlled-pattem antennas 

Use beam steering and beam-shape adaptation to increase throughput and 
avoid interference. 

Frequency band 

5091- to 5150-MHz aeronautical mobile (route) service (AM(R)S) band 
approved during the 2007 World Administrative Radio Conference (WARC 
2007). 

Addition of 5000- to 5030-MHz band is under consideration. 

Spectrum co-user interference 
(i.e., Globalstar satellite) 

BTS sector antenna patterns control direction of radiation. 

Use minimum BTS sector and SS Tx power to achieve required data 
throughput over coverage area. 

SS 

Mounting height 

Avoid low-level structural and temporary blockages. 

MIMO order 

Tx power 

Near-line-of-site and blocked-path performance 
Multipath mitigation 
Mobility dropout avoidance 

Antenna polarization 

Cross-polarized versus spatially separated antennas 

Maximum cell range 

Tx power 

Near-line-of-site and blocked-path performance 
Multipath mitigation 
Mobility dropouts 

Frequency band 

Controlled and set by BTS sector connection 
SS must have matching frequency capability. 

Spectrum co-user interference 
(i.e., Globalstar satellite) 

BTS sector antenna patterns control the direction of radiation. 

Use minimum BTS sector and SS Tx power to achieve required data 
throughputs over coverage area. 

Channel 

bandwidth 

Throughput rate 

Highest throughput application sets the minimum channel bandwidth. 

Mobility performance 

A wider bandwidth enables better channel equalization and better tracking of 
multipath variations during mobility. 

Multipath performance 

Better equalization of short-path multipath with wider channel bandwidths 

Efficient use of spectrum 

Number of channels that fit within the 59-MHz allocated AM(R)S spectrum. 
Refer to Section 6.2.2 for a detailed discussion about center frequency 
selection. 

Co-channel interference 

There are fewer options for nonoverlapping frequency reuse in a large 
number of cells with wide channel bandwidths. 

Hardware limitations 

20-MHz channel bandwidth requires fast digital processing and may not be 
implemented by a particular hardware supplier. 5-MHz and 10-MHz are 
currently supported by the industry 

Modulation 

Adaptive or fixed 

Fixed modulation requires the use of lowest order modulation and lowest data 
throughput; higher order modulation will cause dropouts during mobility. 

Modulation rates 

Use of all specified options maximizes data throughput for fixed and mobile 
SSs. 

Forward error correction (FEC) 
coding rate 

Use of all specified options maximizes data throughput for fixed and mobile 
SSs. 
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TABLE 39.— AEROMACS NETWORK DESIGN CONSIDERATIONS 


Design 

category 

Parameters 

Considerations and system design parameters 

BTS power 
class 

Fade margin 

Fade margin allowance is set during network design to establish link 
reliability. 

Co-channel interference 

Minimize Tx power to stay below the detection threshold of another BTS 
sector in a frequency reuse layout. 

Spectrum co-user interference 
(i.e., Globalstar satellite feeder 
uplinks) 

Minimize Tx power to reduce interference to co-users of the spectrum. 

Range 

Tx power affects the signal-to-noise ratio and modulation rate at the outer 
edge of cell coverage. 

LOS and NLOS operation 

Fade margin allowance increases for NLOS operation. 

Mobile operation 

Fade margin allowance increases for NLOS operation. 

Power amplifier power-output 
limitations 

Orthogonal-frequency-division multiplexing (OFDM) modulation has a high 
peak-to-average ratio, making high Tx power expensive. 

SS power 
class 

Fade margin 

Fade margin allowance is set during network design to maintain link 
reliability. 

Co-channel interference 

Minimize Tx power to stay below the detection threshold of another BTS 
sector in a frequency reuse layout. 

Spectrum co-user interference 
(i.e., Globalstar satellite uplinks) 

Minimize Tx power to reduce interference to co-users of the spectrum. 

Range 

Tx power affects signal-to-noise ratio and modulation rate from the outer 
edge of cell coverage. 

LOS and NLOS operation 

Fade margin allowance increases for NLOS operation. 

Mobile operation 

Fade margin allowance increases for mobile operation. 

Power amplifier power-output 
limitations 

OFDM modulation has a high peak-to-average ratio, making high power 
expensive. 

Media 
Access 
Control 
(MAC) layer 
and physical 
layer (PHY ) 

Maximum mobile speed 

120 km/hr is a value derived from other specified parameters and provides 
guidance about achievable maximum speed. 

The communications operating concept and requirement (COCR) is 160 kt 
(296 km/hr) 

Institute of Electrical and Electronics Engineering (IEEE) 802.16 
specification does not directly support the COCR 160-kt requirement. A 
cost/benefit analysis is needed to assess the benefits of achieving this speed. 

Repeater operation 
(IEEE 802. 16j) 

IEEE 802. 16j is a potential future amendment to the IEEE 802.16 standard 

BS repeater functionality may provide fill-in coverage in shadow areas with 
minimal added radiation and interference. 

Transmitter/receiver 
time-division duplex 
(TDD)/frequency-division 
duplex (FDD) mode 

C-band AM(R)S spectrum allocation width does not support cost-effective 
FDD operation. 

Quality of 
service 
(QoS) 

Time delay 

Services such as voice, and command and control applications will require 
guarantees on maximum time delay allowed. 

Time jitter 

Services that are sensitive to jitter are to be identified. The use of frame 
buffering should be considered for each sensitive application. 

Message priority 

Safety and reliability requirements will help specify message priorities. 

Scheduling 

The scheduling algorithm will take message priority into account along with 
QoS requirements. 

Message integrity 

Security and message integrity guarantees will depend on the type of QoS 
service flow selected. 
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6.7 Upper Networking Layers Analysis 

The proposed AeroMACS broadband wireless specification, based on the WiMAX Forum 
specification for broadband wireless, is meant to deliver increased capacity in support of the varied 
CONOPS requirements for the National Airspace System (NAS). The desired capabilities include a 
scalable, standards based system that avoids single points of failure and supports mutual authentication of 
users and information access (Ref. 79). A key component in ensuring the reliability and resiliency of 
communications networks is a comprehensive approach to securing the end-to-end network. 

Communications in an AeroMACS network is connection oriented. As a result, connections must be 
authenticated, authorized and established prior to any data transmissions. Further, the AeroMACS 
network elements must be authenticated and authorized to each other and to the network prior to the 
establishment of any logical connections. These mechanisms are examples of a multilayered approach to 
communications security (Ref. 57). 

A comprehensive communications network security approach involves a layered scheme to ensure the 
protection of the network at multiple layers. Commonly referred to as “Defense-in-Depth,” a layered 
security approach eliminates a single point of failure and relies on a continuous security policy, security 
training for its users, as well as the application of the appropriate technology to ensure the following 
(Ref. 16): 

• Confidentiality — protection from eavesdropping 

• Integrity — user and management data is not modified while in transit 

• Authentication — assurance that users and devices can authenticate each other 

• Authorization — mechanism that verifies user and AeroMACS service associations 

• Access Control — control authorized access to network resources 

• Availability — prevent Denial of Service or of the AeroMACS network and its attendant resources 

6.7.1 WiMAX Network Reference Model 

Air interface operation between the SSs and BSs at the MAC and PHY layers is specified by the 
IEEE 802. 16-2009 standard. A security framework specified in the MAC security sublayer provides 
confidentiality and authentication across the broadband wireless network. End-to-end security beyond the 
radio interface is not specified in IEEE 802.16-2009. As a result, the WiMAX Network Reference Model 
was developed by the WiMAX Network Working Group to define end-to-end service requirements 
beyond the radio link. A WiMAX deployment includes more than the air interface to link the subscriber 
stations to applications and resources beyond the broadband network. Service requirements include IP 
connectivity, session management, security, QoS, and mobility management. The WiMAX network 
reference model (NRM) illustrated in Figure 41 is a logical representation of the end-to-end network 
architecture. 
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Secure WiMAX Plane 


Figure 41 . — WiMAX reference architecture. 

The WiMAX reference architecture represents a Layer-2 network infrastructure used to establish 
connection-oriented channels for management and data transport at Layers 2 and 3. It is divided into three 
logical parts: 

• Mobile/subscriber stations. — Access devices used by the individuals or entities to access the 
WiMAX radio interface 

• Access Service Network (ASN). — Includes one or more base stations and one or more ASN 
gateways that form the radio access network. Functions of the ASN gateways include location 
management, paging, radio resource management and admission control 

• Connectivity Service Network (CSN). — Provides IP connectivity and all of the IP core network 
functions. Functions include AAA, Billing, DHCP, and policy management of QoS and security. 
Mobility and roaming is also managed at the CSN 

6.7.2 The AeroMACS Security Architecture 

Access to the radio channel is defined at the PHY and MAC layers in an AeroMACS network. It is 
controlled by a series of initialization and authentication steps as specified by the IEEE 802.16-2009 
specification. The initial establishment of a logical AeroMACS environment involves the establishment 
of security associations or mutual authentication between the base station and the subscriber station/ 
mobile station in an AeroMACS network 19 . Mutual authentication support is based on encryption and key 
exchanges using the Privacy Key Management Version 2 (PKMv2) protocol. 

The architecture uses an Internet Engineering Task Force (IETF) extensible authentication protocol 
(EAP) based AAA framework, which is also utilized for service flow authorization, QoS policy control, 
and secure mobility management. It also supports a variety of authentication mechanisms and credentials 


19 Complete AeroMACS Security Assessment is outside the scope of this report. It is addressed by NASA Glenn 
reports. 
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including shared secrets, subscriber identity module (SIM) cards, universal SIM (US1M), universal 
integrated circuit card (UICC), removable user identity module (RU1M) and X.509 certificates. All of 
these mechanisms are suitable for EAP methods satisfying RFC 4017 (Ref. 57). The security functions of 
the AeroMACS security sublayer are illustrated in Figure 42: 


RSA-based Authentication. S A 

authentication control 

EAP 

encapsulation decapsulation 

PKM control management 

Traffic data encryption/' 
Authentication processing 


Control message 
processing 

PHY SAP 

Message authentication 
processing 

L_ 



Figure 42. — IEEE 802.16-1009 MAC security sublayer functions. 


Definitions 

• PKM Control Management: Controls all security components. Various keys are derived and 
generated in this stack. 

• Traffic Data Encryption/Authentication Processing: Encrypts or decrypts traffic data and executes 
the authentication function for the traffic data. 

• Control Message Processing: Processing of various PKM-related MAC messages. 

• Message Authentication Processing: Executes message authentication function. 

• RSA-based Authentication: Performs the RSA-based authentication function using the SS’s 
X.509 digital certificate and the BS’s X.509 digital certificate, when the RSA-based authorization 
is selected as an authorization policy between an SS and a BS. 

• EAP Encapsulation/Decapsulation: Interface with the EAP layer, when the EAP-based 
authorization or the authenticated EAP-based authorization is selected as an authorization policy 
between an SS and a BS. 

• Authorization/S A Control: This stack controls the authorization state machine and the traffic 
encryption key state machine (Ref. 58). 

6.7.3 AeroMACS Network Authentication and Authorization 

The IEEE 802.16-2009 standard outlines a process for initialization of the radio access network as 
illustrated in Figure 43. The process begins when a Mobile/Subscriber Station is powered up and scans 
the allowed downli nk (DL) frequencies to determine the presence of a network. Each MS/SS stores a list 
of operational parameters in nonvolatile memory to synchronize with the most suitable BS. When a BS 
responds with the suitable Uplink (UL) parameters, the SS performs initial ranging with the BS to 
synchronize the timing and power levels required to maintain the UL connection. 
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Figure 43. — Network authentication and authorization process. 

After initial ranging to establish a secure management channel and negotiating basic capabilities 
including PHY modulation and coding schemes as well as bandwidth requirements, the security key 
exchange occurs. The PKMv2 protocol, as specified by IEEE 802.16-2009, is used to manage the key 
exchanges for authentication, authorization and registration between the SS and BS. Utilizing EAP with 
the PKMv2 protocol provides a mechanism for key exchange when mutual authentication is required, as 
recommended in the draft NIST SP 800-120, Recommendation for EAP Methods Used in Wireless 
Network Access Authentication (Ref. 59). 

Each SS is assigned a X.509 digital certificate that is bound to the physical hardware during 
manufacturing. This enables the exchange of authorization keys, key encryption keys, message 
authentication keys and traffic encryption keys that enable the encryption of both the management and 
subsequent data traffic, thereby establishing security associations between the BS and SS in the network. 
The U.S. Government mandates Federal Information Processing Standard (FIPS) 140-2 Advanced 
Encryption Standard (AES) encryption algorithms. The IEEE 802.16-2009 standard specifies at a 
minimum, a 128-bit AES encryption key. 

The security associations are implemented by the MAC layer of the WiMAX standard under the 
MAC Security Sub-layer as illustrated in Figure 44. A security association defines the security parameters 
of a connection, which include encryption keys and algorithms. Security associations fall into three 
categories: authorization, unicast, and multicast services. 
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Figure 44. — WiMAX MAC security sublayer process. 

After the security associations have been completed the BS establishes a connection with the SS the 
registration with the WiMAX network is complete. The SS can now obtain an IP address via the DHCP, 
acquire the current time and any other provisioned parameters and initiate a service flow (Ref. 1 6). 

6.7.4 AeroMACS Potential Vulnerabilities 

AeroMACS as a wireless medium is also susceptible to common wireless security threats. Common 
categories and threats include 

• RF jamming. — a powerful RF signal introduced to the spectrum to overwhelm the system and 
deny service. 

• Scrambling. — precise injections of RF interference during the transmission of specific 
management message thereby degrading overall system performance 

• Management message manipulation. — Spoofing management messages to attempt unauthorized 
access to the network. 

• Man-in-the-middle attacks. — a device or subscriber appears as a legitimate AeroMACS user in 
the network and introduces malicious communications into the data or management channel. 

• Eavesdropping. — the utilization of a traffic analyzer within the range of a BS or SS to capture 
management or data channel traffic. 

6.7.5 Recommendations for End-To-End Security 

The varied service requirements in the NAS CONOPS require a flexible network architecture that can 
secure and separate the various network applications. Given the AeroMACS MAC layer security 
architecture previously mentioned is focused only on the air interface between SS and BS, an end-to-end 
approach shoidd be implemented as to meet the NAS CONOPS requirements. The adherence to the 
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security guidelines specified by the WiMAX Forum and the IEEE 802.16-2009 specification will mitigate 
the various types of threats to the AeroMACS network. The guidelines are summarized as follows: 

• The AeroMACS security framework must support a variety of AeroMACS network topologies 

• The architecture shall accommodate support for strong mutual SS authentication between an SS 
and the AeroMACS network, based on the IEEE 802.16 security frameworks. 

• An SS should be able to support all commonly deployed authentication mechanisms and 
authentication in home and visited operator network scenarios based on a consistent and 
extensible authentication framework. An SS should be able to select between various 
authentication method(s). 

• The architecture shall support data integrity, replay protection, confidentiality and non- 
repudiation using applicable key lengths within the AeroMACS Access Network. 

• The architecture shall accommodate the use of SS initiated/terminated security mechanisms such 
as virtual private networks (VPNs). 

• The architecture shall accommodate standard secure IP address management mechanisms 
between the SS and its CSN. 

• The architecture shall support Fast BS Switching or Macro Diversity Flandover. In the event of a 
change in service between a BS and SS, a procedure to have a SS associate with a secondary BS 
can be implemented. This is an optional specification, but its implementation can enhance 
availability, particularly in a mobile environment. 

The complete security assessment of AeroMACS is out of the scope of this report and is being 
addressed by NASA in a separate document. 

6.7.6 Additional NAS CONOPS Requirements 

The NAS CONOPS requirements will require a separation of the service channels. Deploying virtual 
local area networks (VLANs) is a Layer 2 option for segmenting networks to increase capacity and 
performance while leveraging the same physical infrastructure. A VLAN expands the capacity of a 
broadcast domain with the creation of separate logical broadcast domains or networks. These networks 
can only be connected with a layer 3 switch or router. Classifying or tagging ports or Ethernet frames per 
the IEEE 802. IQ VLAN tagging standard allows for controlled deployment of VLANs across an 
enterprise network (Ref. 57). 

The WiMAX standard supports the use of IEEE 802. IQ. Deploying VLANs at Layer 2 will provide 
the separation of the traffic flows in a WiMAX network. These VLANS can be extended to the back-end 
infrastructure by deploying VLANs on the wired infrastructure. Flowever, the encryption of the traffic 
will only occur in the radio interface as outlined earlier since IEEE 802.16-2009 does not define 
encryption beyond the air interface. Enciyption of the Layer 2 traffic beyond the air interface is not 
specified by the IEEE 802.16-2009 specification. 

In addition, although the WiMAX specification defines communications at the MAC and PHY layers, 
end-to-end transmissions of higher-layer protocols is also supported. The MAC sublayer, illustrated in 
Figure 44, supports the mapping of higher layer protocols to the WiMAX MAC layer for end-to-end 
communications. Linking the WiMAX ASN and MS/SS layers to the CSN and external networks requires 
an IP network as illustrated in Figure 41. 

The WiMAX specification provides the flexibility to extend IP and Ethernet communications across 
the ASN boundaiy with an IP Convergence Sublayer (1P-CS) and an Ethernet Convergence Sublayer 
(Eth-CS) as illustrated in Figure 41. The WiMAXMAC layer is connection-oriented and identifies a 
logical connection between the BS and the MS by a one-way connection identifier (C1D). The ClDs for 
uplink and downlink connections are different. The C1D can be viewed as a temporary and dynamic layer 
2 address assigned by the BS to identify a unidirectional connection between the peer MAC/PHY entities 
and is used for carrying data and control-plane traffic. In order to map the higher-layer address to the 
CID, the CS keeps track of the mapping between the destination address and the respective C1D. These IP 
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and Ethernet channels would be provisioned as VLANS and extended across the end-to-end network 
without the need for an IP network between the ASN and CSN (Ref. 57). This capability in the NAS 
CONOPS would be useful for legacy applications that need to remain at layer 2 to meet QoS or 
performance requirements. 

6.7.7 AeroMACS Network with VPN Overlay 

The IEEE 802.16-2009 standard supports IEEE 802. IQ. Deployment of VLANs at Layer 2 will 
provide the separation of the traffic flows in an AeroMACS network. These VLANS can be extended to 
the back-end infrastructure by deploying VLANs on the wired infrastructure. However, the encryption of 
the traffic will only occur in the radio interface as outlined earlier since IEEE 802.16-2009 does not 
define encryption beyond the air interface (Ref. 79). Encryption of the Layer 2 traffic beyond the air 
interface is not specified by the IEEE 802.16-2009 specification. 

A FIPS validated VPN overlay at Layer 3, with AES 128 encryption at a minimum, will extend 
encryption beyond the BS and ASN gateway. A VPN appliance or router should be placed in front of the 
CSN architecture as illustrated in Figure 45. Clients on the SS may use TLS and 1PSEC solutions that will 
terminate at the VPN gateway. Utilizing a Layer 2 enciyption device could hide the tagged layer 2 
Ethernet frames, thus compromising the mechanism for classification of traffic flows and impeding 
mobility (Ref. 16). 



Figure 45. — WiMAX reference architecture with VPN overlay. 

6.7.8 Upper Networking Layers Summary and Recommendations 

Security in a communications network should be deployed at multiple levels to eliminate potential 
single points of failure. The 802.16-2009 standard defines a number of security enhancements that 
provide defense-in-depth to ensure confidentiality, authentication, authorization, and integrity in addition 
to access controls for the communications infrastructure. They include the use of the Internet Engineering 
Task Force (IETF) EAP -based AAA framework, used for mutual authentication and authorization of 
network elements and subscribers 

The AAA framework is also utilized for service flow authorization, QoS policy control and 
encryption. IEEE 802.16-2009 specifies 128-bit encryption at a minimum. Encryption is used to ensure 
the confidentiality and integrity protection of both management and data traffic. As an added measure of 
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protection, the Federal Government mandates the use of FIPS-approved cryptographic algorithms 
contained in FIPS-validated cryptographic modules. 

In addition, the WiMAX Forum specifies a range of security mechanisms that compliment the IEEE 
802.16-2009 PHY and MAC layer security mechanisms. Solutions include the deployment of VPN 
technologies to provide end-to-end encryption of the data channels at the network layer. Further, the 
development of security policies that incorporate physical and administration controls with the logical 
technology controls will ensure that the NAS CONOPS requirements will operate in a reliable, resilient, 
secure AeroMACS infrastructure. 

6.8 Issues beyond the Scope of IEEE 802.16 Standard 

The IEEE802. 16-2009 standard deals principally with the PHY and MAC network layers. However, 
an operational AeroMACS network must include all networking layers in order to implement user 
authentication, allocation of services and QoS, security, and data delivery. Although an airport can be 
looked at as a small communications zone, many of the upper network layer functions must 
operate on a global basis so that aircraft can operate seamlessly at all locations. 

The following list contains topics that are beyond the scope of the IEEE 802.16-2009 standard. These 
topics are also beyond the scope of RTCA SC-223. Many of these topics are being addressed by the 
WiMAX Forum for commercial network use and their solutions can be the basis for AeroMACS 
solutions. 

AeroMACS topics beyond the scope of IEEE802. 16-2009: 

(1) Network architectures that will segregate safety-critical services from noncritical services and 
assure high QoS with low latency. 

(2) Exchange of user authentication and authorization data on a global basis. AAA database must 
be distributed and consistent on a global basis. 

(3) A method for secure exchange of authentication must be universally implemented on a global 
basis. User authentication infomiation such as Private Key Management security certificates, 
username and passwords must be standardized. A database of this information must be 
immediately available to AeroMACS globally. 

(4) AeroMACS may be implemented with multiple service providers at an airport. Management of 
mobility handover in upper network layers will impact network architectures. 

(5) AeroMACS data traffic load requirement predictions must be established so that initial 
installations at airports will be capable of handling expanding services without re-design and 
modification. This requires a good understanding of ConOps, applications, and their data traffic 
loads. 

(6) A governing body must be responsible for establishing which applications will be allowed to use 
AeroMACS consistent with AM(R)S spectrum limitations. Each application must be assigned a 
service level for Quality of Service. 

(7) A policy should be in place to define and manage the channel allocation for each airport. 

(8) Methods of maintaining AeroMACS profile documentation jointly between RTCA, EUROCAE, 
and the WiMAX Forum must be established so that potential changes can be managed as 
AeroMACS validation tests are conducted and as the WiMAX commercial industry continues to 
develop the WiMAX technology. 
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7.0 Introduction to Volume II 


Volume II describes modifications to the NASA CLE CNS Test Bed to add AeroMACS network 
capability. Test and evaluation results from simulations and AeroMACS Prototype measurements are 
presented. It also provides initial data to be input to the aeronautical mobile-specific AeroMACS design 
specifications. 

Design of an AeroMACS network requires detailed analysis and simulation as well as test 
measurements on candidate airport surfaces. Measurements carried out on candidate airport surfaces 
should provide sufficient data to calibrate key performance tradeoffs that will be modeled by computer 
simulations. One or more mobile SSs should be part of the experimental prototype to assess UL and DL 
performance coverage for initial measurements related to mobile operation. The prototype should provide 
initial quantitative data to aid in the installation of the first phase of an IEEE 802.16-2009-based 
AeroMACS network at other airports of similar complexity. Specific objectives include the following: 

• Assess the full range of aviation profile options for the physical and MAC layer specification, and 
recommend initial values for each parameter in the profile. 

• Verify functional operation of the physical and MAC layers within the recommended profile. 

• Obtain measurements at various locations on the airport surface to calibrate coverage models for 
the UL and DL systems. 

• Measure multichannel performance with sectored BS antennas to support airport layout design for 
future installations. 

• Validate operation of AeroMACS while connected to other airport network systems; for example, 
connected to an airport IP network. 

In addition, data collected from a prototype at a specific airport location should be analyzed relative 
to other experimental data from airport measurements. This will help to reinforce conclusions and 
uncover inconsistencies. 

In order to meet the prototype objectives, it is recommended that at least two BSs be utilized that have 
overlapping coverage on the airport surface. In addition, fixed and mobile SSs should be utilized to obtain 
UL and DL coverage data and to be able to evaluate parameter settings under a variety of conditions. 

An AeroMACS network having these considerations and conforming to the architecture described in 
Section 5.3 is now implemented in the NASA-Glenn CNS Test Bed. The physical installation, a set of 
four evaluation tests, and evaluation results are described in Volume II. 

Special Committee SC-223 was established within the RTCA aviation industry consortium to 
establish standards for AeroMACS. The principal products of this special committee are a set of final 
recommendations for a system profile to be delivered in September 2010 and a Minimum Operational 
Performance Standards (MOPS) document to be delivered in December 201 l(Ref. 20). EUROCONTROL 
established a similar work group, WG-82, that is chartered to develop an AeroMACS profile. SC-223 
and WG-82 work cooperatively to develop a common profile document that will be provided as 
recommendations for consideration by ICAO. Section II describes this process and the resulting 
recommendations. 
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Appendix A. — Acronyms and Abbreviations 

This appendix identifies acronyms and abbreviations used throughout this document. 


A/A 

AAtS 

A/C 

A/G 

AAA 

AAC 

AATS 

ACARS 

ACI 

ACSTS 

ADAS 

ADDS 

ADS-B 

ADS-C 

ADSx 

AEEC 

AeroMACS 

AES 

AFB 

AFSS 

AIM 

Airp Ops 

AISR 

ALS 

ALSF 

AM(R)S 

AMS(R)S 

ANSP 

AOC 

NASA/CR— 2011 


air to air 

Aircraft Access to SWIM 

aircraft 

air to ground 

authentication, authorization, and accounting 
Airline Administrative Communications 
Aircraft Access to SWIM 

Aircraft Communications Addressing and Reporting System 
Airport Council International 

Aerospace Communication Systems Technical Support contract 

AWOS Data Acquisition System 

Aviation Digital Data Service 

automatic dependent surveillance — broadcast 

automatic dependent surveillance — contract 

automatic dependent surveillance — next generation 

Airlines Electronic Engineering Committee 

Aeronautical Mobile Aircraft Communications System 

Advanced Encryption Algorithms 

Air Force base 

Automated Flight Service Station 
Aeronautical Information Management 
airport operation 

Aeronautical Information System Replacement 
airport lighting system 

approach lighting with sequenced flashing lights 
aeronautical mobile (route) service 
aeronautical mobile satellite (route) service 
air navigation service provider 
aeronautical operational control 
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AOCDLL 


AP-17, -30 

APT 

ARC 

ARCTR 

ARFF 

ARINC 

ARSR 

ARTCC 

ARTS 

ASDE-X 

ASN 

ASN-GW 

ASN-GW-DP 

ASN-GW-EP 

ASOS 

ASR 

ATC 

ATCSCC 

ATCT 

ATFCM 

ATIS 

ATL 

ATM 

ATN 

ATO 

ATS 

ATSP 

ATSU 

AWIPS 

AWOS 

AZ 


AOC Data Link Logon 
Action Plan 17, 30 
Airport 

airport reference code 

aeronautical center in Oklahoma City, Oklahoma 

Aircraft Rescue and Firefighting building (at Cleveland Flopkins International 
Airport) 

Aeronautical Radio Incorporated 

air route surveillance radar 

air route traffic control center 

Automated Radar Terminal System 

Airport Surface Detection Equipment — Model X 

access service network 

access service network gateway 

access service network gateway — decision point 

access service network gateway — enforcement point 

automated surface observation systems 

airport surveillance radar 

air traffic control 

air traffic control system command center 

air traffic control tower 

air traffic flow and capacity management 

Automatic Terminal Information Service 

Atlanta International Airport 

air traffic management 

aeronautical telecommunications network 

Air Traffic Organization 

air traffic services 

air traffic service provider 

air traffic services unit 

Advanced Weather Interactive Processing System 
Automated Weather Observing System 
azimuth 
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BASOP 

base operations 

BER 

bit error rate 

BLOS 

beyond line of sight 

BS 

base station 

BTS 

base transceiver station 

BUEC 

backup emergency communications 

BW 

bandwidth 

BW1 

Baltimore-Washington International Airport 

C&P 

crossing and passing 

CAB1NLOG 

Cabin Log Book Transfer 

CANRAD 

Canadian Radars 

CDA 

Continuous Descent Arrivals or Continuous Descent Approach 

CDM 

collaborative decision making 

CDT1 

cockpit display of traffic information 

CFR 

Code of Federal Regulations 

C1D 

connection identifier 

C1NR 

carrier-to-interference and noise 

C1WS 

Corridor Integrated Weather System 

CLE 

Cleveland Flopkins International Airport, Cleveland, Ohio 

CMF 

Consolidated Maintenance Facility 

CNS 

communication, navigation, and surveillance 

CO 

commercially-operated 

COCR 

communications operating concept and requirements 

COM 

communications 

ConOps 

concepts of operation 

ConUse 

concepts of use 

CP 

cyclic prefix 

CPDLC 

controller pilot data link communications 

CPE 

customer premise equipment (same as subscriber station) 

CSN 

Connectivity Service Network 

CTA 

Controlled Time of Arrival 

D/L 

data link 

Data Comm 

data communications 
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dATIS (D-ATIS) 

DC 

DCG 

DCS 

DFU 

DHCP 

DHS 

DINS 

DL 

DME 

DoD 

D-OTIS 

D-RVR 

D-SIG 

D-SIGMET 

DSB AM 

DSR 

DSS 

D-TAXI (D-Taxi) 

DTS 

DYNAV 

EA 

EAP 

ECG 

ECS 

ENGINE 

ERAM 

ERIDS 

ERT-VR 

ES 

ES 

ETH-CS 

ETVS 


Digital Automatic Terminal Information Service 

data communications 

data communications gateway 

data communications system 

display functional unit 

Dynamic Host Configuration Protocol 

Department of Homeland Security 

Defense Internet NOTAM (Notice to Airmen) services 

downlink — base station to subscriber station data-flow direction 

distance measuring equipment 

Department of Defense 

data link operational terminal information service 

data link runway visual range 

data link surface information and guidance 

data link significant meteorological information 

double-sideband amplitude modulation 

dynamic source routing 

decision support system 

data link taxi clearance 

Dedicated Telecom Services 

dynamic route availability 

enterprise architecture 

extensible authentication protocol 

En Route Communications Gateway 

emergency communications systems 

Engine Performance Reports 

En Route Automation Modernization 

En Route Information Display System 

extended real time — variable rate 

Engineering Study 

Extended Squitter 

Ethernet convergence sublayer 

Enhanced Terminal Voice Switch 
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EUR 

Europe 

EUROCAE 

European Organization for Civil Aviation Equipment 

EUROCONTROL 

European Organisation for the Safety of Air Navigation 

F&F 

flight and flow 

FAA 

Federal Aviation Administration 

FANS-1/A+ 

Future Air Navigation System — 1/A+ version 

FBWTG 

FAA Bulk Weather Telecommunications Gateway 

FC1 

future communications infrastructure 

FCS 

Future Communications Study 

FDD 

frequency-division duplex 

FEC 

forward error correction 

FFT 

fast Fourier transform 

FIPS 

Federal Information Processing Standard 

FIS 

flight information service 

FL1PCY 

flight plan consistency 

FLTLOG 

Flight Log Transfer 

FLTPLAN 

Flight Plan Data 

FLTSTAT 

Flight Status 

FMS 

flight management system 

FOC 

Flight Operations Center 

FPR 

Final Program Requirements 

FREETXT 

Free Text 

FRS 

future radio system 

FTP 

File Transfer Protocol 

FUEL 

Fuel Status 

FY 

fiscal year 

G/A 

general aviation 

G/G 

ground to ground 

GA 

general aviation 

GATES 

Gate and Connecting Flight Status 

GBT 

ground-based transceiver 

G1 

general information 

G1S 

geographical information system 
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Glenn 

Glenn Research Center 

GO 

government operated 

GPS 

Global Positioning System 

GS 

ground station 

GSC 

ground station controller 

GTWY 

gateway 

GW 

gateway 

HCS 

host computer system 

HF 

high frequency 

HPA 

high performance airspace 

IAP 

Internet Access Point 

ICAO 

International Civil Aviation Organization 

ID 

identification 

IDS 

Information Display System 

IEEE 

Institute of Electrical and Electronics Engineering 

IETF 

Internet Engineering Task Force 

ILS 

instrument landing system 

IP 

Internet Protocol 

1PCS 

IP convergence sublayer 

Iperf 

network testing tool 

ITP 

In-Trail Procedure 

ITU 

International Telecommunications Union 

1TWS 

Integrated Terminal Weather System 

JPDO 

Joint Planning and Development Office 

Kbps 

Kilobits 

LAN 

local area network 

LCGS 

low-cost ground surveillance 

LINK 2K+ 

European SESAR (Single European Sky ATM Research) program 

LLWAS 

Low-Level Wind Shear Alert System 

LOADSHT 

Load Sheet Request/Transfer 

LOC 

localizer 

Loc 

location 

LOS 

line of sight 
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LRR 


M&S 

MAC 

MAINTPR 

MAINTRT 

M-ary 

MASPS 

Mbps 

Mhz 

MIMO 

MITRE CAASD 

MLAT 

MLS 

MM 

Mode S 

MOPS 

MS 

MSS 

NADIN 

NAS 

NASA 

NASA-CLE 

NASA-EA 

NASAD 

NASCR 

NAS-SR 

NAV 

NAVAIDS 

NDB 

NEXCOM 
N EXRAD 
NextGen 


long-range radar 

merging and spacing 

Media Access Control 

Maintenance Problem Resolution 

Real Time Maintenance Information 

digital transmission of two or more bits at a time 

minimum aviation system performance standards 

megabit per second 

megahertz 

multiple input, multiple output 

MITRE Corporation’s Center for Advanced Aviation System Development 

multilateration 

microwave-landing-system 

middle marker 

Mode Select secondary surveillance Beacon System 

Minimum Operational Performance Standards 

mobile station 

Mobile-satellite service 

National Airspace Data Interchange Network 

National Airspace System 

National Aeronautics and Space Administration 

NASA Glenn Research Center and Cleveland Hopkins 
International Airport 

National Airspace System Enterprise Architecture 

NAS architecture document 

NASA Common Reference System 

National Airspace System — System Requirements 

navigation 

navigation aids 

nondirectional radio beacon 

Next Generation Air/Ground Communications 

Next Generation Radar 

Next Generation Air Transportation System 
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NFU 

National Weather Service Filter Unit 

N1PRNET 

Nonclassified Internet Protocol Router Network 

N1WS 

NAS Integrated Web Services 

NLOS 

non line of sight 

NMS 

Network Management System 

NNCC 

National Network Control Centers 

NNEW 

NextGen Network Enabled Weather 

NOAA 

National Oceanic and Atmospheric Administration 

NOTAM 

Notice to Airmen 

NP1AS 

National Plan of Integrated Airport Systems 

NRM 

network reference mode 

nRT 

non real time 

nrtPS 

non-real-time polling service 

NW1S 

NAS-wide Information Services 

NWS 

National Weather Service 

O&M 

operations and maintenance 

OAS 

Oceanic Automation System 

ODU 

outdoor unit 

OFDM 

orthogonal-ffequency-division multiplexing 

OFDMA 

orthogonal-ff equency-division multiple access 

01 

operational improvement 

OM 

outer marker 

0001 

Out-Off-On-ln 

Ops IP 

operations IP 

Ops 

operations 

OPUS 

Online Positioning User Service 

ORIS 

operational en route information service 

OSED 

Operational Services and Environment Definition 

OTIS 

operational terminal information service 

OV-1, OV-2 

operational views 

PA1RAPP 

paired approach 

PC 

personal computer 

PER 

packet error rate 
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PHY 

physical 

P1AC 

Airport Peak Instantaneous Aircraft Counts 

PIREP 

pilot report 

PKMv2 

Privacy Key Management Version 2 

PLA 

project-level agreement 

PoE 

Power over Ethernet 

POSRPT 

Position Report 

PPD 

pilot preferences downlink 

Pri Hangar 

primary hangar 

PRM 

Precision Runway Monitor 

PSN 

packet switched network 

PV6 

plan view 6 

QAM 

quadrature amplitude modulation 

QoS 

quality of service 

QPSK 

quadrature phase-shift keying 

RAPCO 

Radar Approach Control 

RASP 

Regional ADAS (Automated Weather Observation Station Data Acquisition System) 
Service Processor 

RCAG 

remote communications air to ground 

RCE 

radio control equipment 

RCE-C 

RCE at control site 

RCE-R 

RCE at remote (transmitter/receiver) site 

RCO 

remote communication outlet 

RCP 

required communication performance 

RDVS 

Rapid Deployment Voice Switch 

RE&D 

research, engineering and development 

RF 

radiofrequency 

RRM 

radio resource management 

RSS1 

received signal strength indication 

RTCA 

RTCA, Inc. (founded as Radio Technical Commission for Aeronautics) 

rtPS 

real-time polling service 

RTR 

remote transmitter/receiver 

RU 

remote unit 
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RUC 

rapid update cycle 

RU1M 

removable user identity module 

RVR 

runway visual range 

Rx 

receiver 

SAMS 

Special Use Airspace Management System 

SARPs 

standards and recommended practices 

SATCOM 

satellite communications 

SC 

single carrier; special committee 

SCa 

single carrier access 

SCS 

Sensor Control Subsystem (ADAS, AWOS Data Acquisition System) 

SE 

system engineering 

SEM 

system engineering manual 

SESAR 

Single European Sky ATM Research 

S1GMET 

significant meteorological information 

SIM 

subscriber identity module 

SITA 

Societe Internationale de Telecommunications Aeronautiques 

SOA 

service-oriented architecture 

SOAMOM 

service-oriented architecture messaging oriented middleware 

SOC 

Service Operations Center 

socc 

Security Operations Control Center 

SONET 

synchronous optical networking 

SPR 

safety and performance requirement 

SR 

system requirement 

SRD 

system requirements document 

SRR 

short-range radar 

SS 

subscriber station 

SSR 

secondary surveillance radar 

StarACS 

Star Automatic Configuration Server (for WiMAX (Worldwide Interoperability 
Microwave Access) networks) 

STARS 

Standard Terminal Automation Replacement System 

surv 

surveillance 

SV-1, SV-2 

system views 

SWIM 

System Wide Information Management 
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SWLOAD 

Software Foading 

SYSCO 

system-supported coordination 

TACAN 

tactical air navigation 

TAP/CDA 

Tailored Arrival Procedure/Continuous Descent Approach (Arrival) 

TBO 

trajectory-based operations 

TCP 

transmission control protocol 

TDD 

time-division duplex 

TDLS 

tower data link system 

TDM A 

time-division multiple access 

TDWR 

Terminal Doppler Weather Radar 

TECHLOG 

Technical Fog Book Update 

TFDM 

Tower Flight Data Manager 

TFM 

traffic flow management 

TFR 

temporary flight restrictions 

THEVAN 

Terrestrial Hybrid Environment for Verification of Aeronautical Networks 

T1BA 

Traffic Information Broadcast by Aircraft 

TM 

Traffic Management 

TMI 

Traffic Management Initiatives 

TMA 

terminal maneuvering area 

TRACO 

facility type for TRACON 

TRACON 

Terminal Radar Approach Control Facility 

TVS 

Terminal Voice Switch 

TW1P 

Terminal Weather Information for Pilots 

Tx 

transmitter 

UAS 

unmanned aircraft system 

UAT 

universal access transceiver 

UDP 

User Datagram Protocol 

UGS 

unsolicited grant service 

UHF 

ultra-high frequency 

U1CC 

universal integrated circuit card 

UF 

uplink — subscriber station to base station data-flow direction 

UPF1B 

Update Electronic Fibrary 

URCO 

urgent contact 
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USAS 

use 

USIM 

ves 

VDL 

VHF 

VLAN 

VoIP 

VOLPE 

VOR 

VPN 

vses 

WAAS 

WAKE 

WARC 

WARP 

WG 

WiMAX 

WINS 

WirelessHUMAN 

WirelessMAN 

WJHTC 

WMD 

WMS 

WMSCR 

WRC 

WRS 

WTWD 

Wx 

WXGRAPH 

WXRT 

WXTEXT 


User Services & Applications Survey 
United States Code 
universal SIM 

Voice Communications System 

very high frequency digital li nk 

very high frequency 

virtual local area network 

digital voice over Internet Protocol 

John A. Volpe National Transportation Systems Center 

very high frequency (VHF) omnidirectional range 

virtual private network 

Voice Switching and Control System 

Wide Area Augmentation System 

wake vortex 

World Administrative Radio Conference (now World Radiocommunication 
Conference) 

Weather and Radar Processor 
working group 

Worldwide Interoperability Microwave Access 

Weather Information Network Server 

wireless high-speed unlicensed municipal area network 

wireless municipal area network 

William J. Hughes Technical Center 

wake mitigation departure 

wide-area master station 

Weather Message Switching Center Replacement 

World Radiocommunication Conference 

WAAS (wide-area augmentation system) reference stations 

Wake Turbulence Mitigation for Departures 

weather 

Graphical Weather Information 
Real-time Weather Reports for Met Office 
Textual Weather Reports 
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4-D 

4DLINK 

4DT 


four dimensional (latitude, longitude, altitude, and time) 

proposal for the next data link package that targets initial four-dimensional 
trajectories and airport services (This capability fits in Implementation Package 2 as 
identified by the Single European Sky ATM Research (SESAR) Master Plan.) 

four-dimensional trajectory (latitude, longitude, altitude, and time) 
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Appendix B. — RTCA National Airspace System Concept of Operations 
Applicable to the Proposed Aeronautical Mobile Airport 
Communications System (AeroMACS) 

AeroMACS could provide a communication link to transfer surveillance and weather information, 
facilitate flight and resource management, and enable exchange of aeronautical information in the future 
NAS. Table 40 to Table 44 document the select RTCA NAS ConOps (Ref. 14) found applicable to the 
proposed AeroMACS. 

In addition to the relevant section number, the “Relevant text” column presents the specific text from 
the NAS ConOps document pertaining to the identified type of information being exchanged and/or 
service provided. The “Relevant text” in these tables is copyrighted by RTCA, Inc., and is being used 
with permission. 20 


TABLE 40.— THE ROLE OF SURVEILLANCE INFORMATION— RTCA NATIONAL AIRSPACE SYSTEM (NAS) 
CONCEPT OF OPERATIONS (CONOPS) APPLICABLE TO THE PROPOSED AEROMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

S-l 

1.5.2 

Traffic information collected by surveillance systems is transmitted to properly equipped aircraft. 
Thus equipped users have position information of appropriate aircraft available to support flight 
deck decisions. 

S-2 

1.5.3 

2nd bullet 

Enhanced CNS [communications, navigation, and surveillance] systems and automation in 
aircraft complement automation aids on the ground pennitting more autonomous operations. This 
improved autonomy combined with greater ability to share information pennits workload to be 
distributed between service provider and operator in a balance appropriate for the operations 
being conducted. 

S-3 

4.1.3 

Accurate airport environmental information, including traffic, pennits appropriately equipped 
aircraft to navigate on the airport surface with almost no forward visibility. 

S-4 

4.2.2 

The proliferation of CDTI [cockpit display of traffic information] avionics and supporting ground 
infrastructure takes place in this time frame. The ground system that receives aircraft position 
reports also broadcasts traffic information and a complete set of graphical and text weather 
products . . . Safety is enhanced by situation displays that depict airborne and surface traffic as 
well as aerodrome information. 

S-5 

4.3.2 

1 st paragraph 

... In addition, ground-based surveillance data is shared with users as a safety enhancement for 
preventing incursions. 

S-6 

5.1.3 

2nd paragraph 

Virtually all aircraft are equipped to provide position and intent information, and to receive 
position and intent data from other aircraft. 


20 The complete RTCA NAS ConOps (and other RTCA documents) may be purchased from RTCA, Inc., 1828 L St., 
N.W., Suite 805, Washington, DC 20036 (202-833-9339, http://www.rtca.org). 
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TABLE 41. —THE ROLE OF WEATHER INFORMATION— RTCA NATIONAL AIRSPACE SYSTEM (NAS) 
CONCEPT OF OPERATIONS (CONOPS) APPLICABLE TO THE PROPOSED AEROMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

W-l 

1.4 

2nd bullet 

In addition to this pool of common information, SWIM [System Wide Information Management] 
provides context-sensitive information to NAS elements that require the information. (This 
includes flight deck access to the information, such as weather and resource status.) 

W-2 

1.5.2 

9th bullet 

A SWIM system is developed by the service provider to distribute timely and consistent 
information across the NAS for both user and service provider planning . . . The system serves as 
an avenue for greater exchange of electronic data and information between users and service 
providers including. . . - Dynamic information including but not limited to current and forecast 
weather, radar summaries, hazardous condition warnings, information on updated airport and 
airspace capacity constraints Temporary Flight Restrictions (TFR), and Special Use Airspace 
(SUA). 

W-3 

1.5.3 

6th bullet 

There are continued advancements in the scope and accuracy of the weather infonnation available 
to the service provider and use throughout the NAS, including automatic simultaneous broadcast 
of hazardous weather alerts for wind shear, turbulence, microburst, gust fronts; and areas of 
precipitation, lightning, icing, and low cloud ceilings and visibility. SWIM provides access to this 
information to all service providers and to participating aircraft via data link. Improved weather 
information integrated into DSSs and disseminated via data link reduces encounters with 
hazardous weather. 

W-4 

2.1.1 

TFM [traffic flow management] service providers monitor traffic, weather, and infrastructure. . . . 
Improved infonnation exchange among users and service providers enables shared insight about 
weather, demand, and capacity constraints which enhances the users understanding of NAS status 
and TFM initiatives. 

W-5 

2.2.1 

1 st paragraph 

Users have access to an increasing amount of NAS information including airport status and 
acceptance rate, composite weather infonnation developed collaboratively by the FAA and users 
to assure a common projection of future weather. 

W-6 

3.1.2 

1 st paragraph 

A common Geographical Infonnation System (GIS) format is used to store all NAS information 
including terrain, obstacle, weather, and navigation, surveillance and communication coverage 
information. This infonnation is available via SWIM to all service providers and users. 

W-7 

3.2.1 

4th paragraph 

Data link-equipped users load the flight plan directly into the Flight Management System (FMS). 
The user obtains a complete weather briefing for the proposed route via the FOC [Flight 
Operations Center] computer. In addition, system-wide infonnation is obtained via the FOC 
SWIM interface. 

W-8 

3.2.3 

3rd paragraph 

Greater use of electronic flight planning, navigation database updates and weather briefing 
services via SWIM results in the routine transfer of preflight planning data to the flight deck. 
Dynamic safety-critical (e.g. turbulence, icing) and other flight plan is data linked directly to 
aircraft for use during flight. 

W-9 

4.1.1 

2nd paragraph 

The introduction of data-linked meteorological infonnation improves overall situational 
awareness. Properly equipped aircraft receive graphical weather information via data link, 
including current observations, pilot reports, hazardous phenomena in both graphic and text 
format, and winds aloft information. 

W-10 

4.1.2 

3rd paragraph 

Clearances, airport information, and weather conditions (e.g., current, forecast, hazardous) are 
provided over data link to more users at more airports. 

W-ll 

4.1.2 

4th paragraph 

The system provides access to airport environmental infonnation, arrival, departure, and taxi 
schedules, airborne and surface surveillance infonnation, flight information, ATIS [Automatic 
Terminal Information System] and other weather information, and TFM initiatives. 

W-12 

4.1.3 

1 st paragraph 

Hazardous weather alerts are automatically and simultaneously broadcast to aircraft via data link 
and service providers via SWIM. 

W-13 

4.2.1 

1 st paragraph 

Many users continue to use Aircraft Communications Addressing and Reporting System 
(ACARS) as a source of data linked information. ATIS and other weather information are 
received via data link or by voice. 

W-14 

4.2.2 

3rd paragraph 

The ground system that receives aircraft position reports also broadcasts traffic information and a 
complete suite of graphical and text products, including precipitation/lightning, icing, low 
ceiling/visibility maps, surface hazards, and wind shear and turbulence information, as well as 
site-specific weather reports and forecasts. Safety is enhanced through the use of situation 
displays that depict airborne and surface traffic as well as aerodrome infonnation. 
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TABLE 41. —THE ROLE OF WEATHER INFORMATION— RTCA NATIONAL AIRSPACE SYSTEM (NAS) 
CONCEPT OF OPERATIONS (CONOPS) APPLICABLE TO THE PROPOSED AEROMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

W-15 

4.3.1 

1 st paragraph 

SWIM and ACARS enhance the service provider’s ability to provide data products such as 
NOTAMs [Notices to Airmen] and meteorological information to the airport vicinity. Although 
weather infonnation and advisories continue to be available via traditional means, there is 
increased use of automation to collect and package the infonnation and increased use of data link 
to disseminate routine and hazardous weather and traffic information. 

W-16 

4.3.2 

1 st paragraph 

SWIM provides access to weather and infonnation via data link to flight crews, allowing them to 
develop near-real-time picture of the surrounding environment. SWIM and data link also expedite 
the service provider’s task of providing data products such as NOTAMs and meteorological 
infonnation for the airport vicinity when changed or needed [b]y the user. 


TABLE 42.— IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT INFORMATION— RTCA NATIONAL 
AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

FM-1 

1.5.2 

9th bullet 

A SWIM [System Wide Information Management] system is developed to distribute timely and 
consistent information. ...[Including]: - Flight infonnation on each flight, including the filed 
flight profile and all amendments, first movement of the aircraft, wheels-up, position data in 
flight, touchdown time, gate or parking assignment, and engine shutdown. 

FM-2 

1.5.2 

1 3th bullet 

The flight planning system accommodates all uses of the airspace as the flight profile evolves to 
include real time SUA [Special Use Airspace] operations scheduling infonnation. 

FM-3 

1.5.2 

1 4th bullet 

By integrating all airspace management systems, the NAS achieves the technical goal of 
providing in a timely manner the airspace necessary to execute the flight profile. The ATM [air 
traffic management] system manages airspace based on each user's needs, including proximity 
to the user’s base of operations. As a result, more airspace, including special use, is made 
available to more users with increased efficiency. 

FM-4 

2.2.1 

1 st paragraph 

Users have access to an increasing amount of NAS infonnation, including airport status and 
acceptance rate and composite weather information developed collaboratively by the FAA 
[Federal Aviation Administration] and users to ensure a common projection of future weather. 
Improved individual support capabilities use investigative operations and develop individual 
strategies to mitigate demand-capacity imbalances and their effect on the individual user fleets. 
Sharing strategies with the ATCSCC [air traffic control system command center] allows service 
providers to evaluate conditions based on user intention rather than published schedules. 

FM-5 

2.2.2 

1 st paragraph 

With the increasing ability to maintain common situation awareness, users plan flight profiles 
that consider known constraints and provide the best advantage to their operations. 

FM-6 

2.2.2 

2nd paragraph 

... In addition, the flight planning system expands to offer users the opportunity to provide 
alternative profiles for flights. These alternative profiles are tested on a continuing basis as trial 
plans that are selected if conditions do not develop as foreseen. 

FM-7 

2.2.3 

1 st paragraph 

. . .Within that constraint and allocation, the NAS has the ability to conduct a SYSCO [system- 
supported coordination] auto-negotiation of the flight profile to best meet the user's need within 
that user’s NAS resource allocation. The systems interactively re-plan each flight against both 
current constraints and any ancillary problems that arise through the execution of the initiative. 

FM-8 

3 

1 st bullet 

Elements of SWIM are used to obtain and distribute flight-specific data and aeronautical 
information, including international coordination of planned flight trajectory. 

FM-9 

3 

6th bullet 

Real-time trajectory updates reflect more realistic departure times, resulting in more accurate 
traffic load predictions, and increased flexibility due to the imposition of fewer restrictions. 

FM-10 

3 

2nd bullet 

As the information available through SWIM increases, a more collaborative role for users 
evolves based on the access to accurate real-time NAS information for improved flight planning. 
Examples of this infonnation include current and predicted SUA status, infrastructure status, 
traffic density, and prevailing TFM [traffic flow management] initiatives. 

FM-1 1 

3 

3rd bullet 

Decision support suites are available for both interactive preflight planning with the service 
provider as well as changes by the pilot and/or dispatcher during the course of the flight. 

FM-12 

3.1.1 

3rd paragraph 

There is real-time sharing of system demand and the virtual ATM information, enabling service 
providers to collaboratively interact with the user and to mutually develop solutions to problems. 
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TABLE 42.— IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT INFORMATION— RTCA NATIONAL 
AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS 


ID 

NAS ConOps 
section 

Relevant text ( Ref. 14) 

FM-12 

3.1.2 

2nd paragraph 

Flight plan infonnation is incorporated into the flight profile. This profile can be as simple as the 
user’s preferred path or as detailed as a time-based trajectory that includes the user’s preferred path 
and preferred climb and descent profiles. The climb and descent profiles may include extended 
periods of continuous change. This is similar in nature to a discretionary clearance (climb or 
descent) but is part of the flight planning process and, ultimately, the approved flight profile. This 
negotiated profile is available both to the user and to service providers across the NAS. 

FM-13 

3.1.2 

4th paragraph 

At the completion of the planning process, the user supplies the service provider with both the 
flight profile that best balances the NAS constraints and the user’s preferred flight profile. This 
information, including any subsequent changes, is available electronically to all service 
providers until the tennination of the flight. 

FM-14 

3.1.3 

1 st and 2nd 
paragraph 

Interactive flight planning capabilities with immediate access to real-time data are fully 
implemented and are available throughout the flight to the flight deck, FOC [Flight Operations 
Center], and service provider. User-preferred routing is available to all properly equipped 
aircraft for both domestic and international flights. Controlled Times of Arrival (CTA) are the 
primary method for regulating flows in the planning, tactical, and strategic timeframes. 

The flight profile evolves with changes to operations to allow greater flexibility in user 
preferences, including the planning and filing of parabolic flight profiles. 

FM-15 

3.2.1 

2nd paragraph 

The TFM infonnation network enables a two-way exchange of real-time information. Using 
flight plan information, flow managers determine when either airport or airspace demand is 
predicted to exceed capacity, thereby warranting some type of flow management initiative. NAS 
users receive information about projected areas of concern and revise their plans on a real-time 
basis. 

FM-16 

3.2.1 

4th paragraph 

Data link-equipped users load the flight plan directly into the aircraft Flight Management 
System (FMS). The user obtains a complete weather briefing for the proposed route via the FOC 
computer. In addition, system- wide infonnation is obtained through the FOC SWIM interface. 

FM-17 

3.2.2 

1 st paragraph 

SWIM ensures a continuously updated infonnation base of NAS items, including service 
constraints and infrastructure status. The flight planner uses this data to prepare a flight profile 
by performing a probe for the user-preferred route against the known system constraints. User 
DSSs [decision support systems] using infonnation available via SWIM analyze the route that 
most closely balances user preferences and constraints. The use of CTAs [Controlled Times of 
Anival] continues to expand across NAS resources. As conditions change during the planning 
phase or during the flight, the user is notified, and he/she is able to interactively determine the 
impact of the changes on the flight and modify the flight profile as desired. 

FM-18 

3.2.2 

2nd paragraph 

The status of active and proposed flights, as well as real-time updates to reflect more realistic 

departure times (e.g., the latest planned departure times) are available to users SWIM and 

SYSCO [system-supported coordination] facilitate more effective CDM [collaborative decision 
making] between the FOC and service provider. 

FM-19 

3.2.2 

4th paragraph 

Users without an FOC capability access the same flight data used by all other system users and 
service providers via appropriate devices. They are able to enter a command and be transferred 
to a service provider for clarification of the infonnation. Depending on the user’s equipment, 
this dialog is by voice or through electronic messaging. For users equipped with data link, the 
capability exists to load a flight profile directly into the aircraft FMS [flight management 
system]. Other users can store the flight profile information on disk and upload it into the 
aircraft’s avionics for use. 

FM-20 

3.2.2 

9th paragraph 

. . . SWIM enables domestic and international users and service providers to access flight profiles 
and associated SUA data. 

FM-21 

3.2.3 

1 st paragraph 

SWIM and Omni-SYSCO support an interactive flight planning capability for all properly 
equipped users to aid in filing user-preferred departure- to -destination flight profiles. . . . 


NASA/CR — 201 1-216997/VOL1 


126 




TABLE 42.— IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT INFORMATION— RTCA NATIONAL 
AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS 


ID 

NAS ConOps 
section 

Relevant text ( Ref. 14) 

FM-22 

3.3.2 

1 st and 2nd 
paragraphs 

SWIM infonnation improves the user’s ability to create a flight profile, which facilitates the 
automatic generation of a flight profile containing either the user’s preferred flight path or a 
more detailed time-based trajectory within the known ATM system constraints. Potential 
problems are automatically displayed to the planner for reconciliation. Upon filing, the flight 
profile is updated, as necessary, along with all affected projections of NAS demand. 



As conditions change, SWIM (in concert with SYSCO) allows the planner to access information 
used to detennine the impact of the changes on the flight. Intelligent agents are introduced in 
this period to identify the best alternatives in light of ATM system changes and user preferences. 
SWIM infonnation is available to all users and service providers until the termination of the 
flight. Information such as runway preferences and aircraft weight or infonnation to support 
flight following can be added during the planning phase or during flight. 

FM-23 

4.1.2 

3rd paragraph 

Clearances, airport infonnation, and weather conditions (e.g., current, forecast, hazardous) are 
provided over data link to more users at more airports. Taxi routes and positions of other aircraft 
are data linked and displayed in appropriately equipped aircraft. The receipt of taxi routes over 
data link relieves communication frequency congestion. Pilot situational awareness and safety 
are enhanced with an integrated display of the aircraft’s position, taxi route, and hazards. 

FM-24 

4.1.2 

4th paragraph 

Access to real-time data for surface movement DSSs makes for an increasingly integrated NAS. 
.... The system provides access to airport environmental information; arrival, departure, and taxi 
schedules; airborne and surface surveillance information; flight infonnation; ATIS [Automatic 
Terminal Information System] and other weather information; and TFM initiatives. . . . 

FM-25 

4.1.2 

5 th paragraph 

On taxi out, the flight’s time-based trajectory is updated in SWIM, and projections are made 
based on prevailing traffic conditions. 

FM-26 

4.3.1 

4th paragraph 

. . .the service provider’s ability to plan surface movement improves as timely traffic information 

becomes available Both the initial values and subsequent adjustments are incorporated into 

the surface management infonnation system to ensure consistency and an integrated approach 
across systems 
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TABLE 43.— IDENTIFICATION OF THE ROLE OF AERONAUTICAL INFORMATION— RTCA NATIONAL 
AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (CONOPS) APPLICABLE TO THE PROPOSED AEROMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

A-l 

1.5.2 

9th bullet 

A SWIM [System Wide Information Management] system is developed by the service provider to 
distribute timely and consistent information across the NAS . . .including. . . 

Static data, such as electronic navigation data, maps, charts, airport facility guides, and published 
Notices to Airmen (NOTAMs) is available directly from the Internet as well as various 
intranets... 

Dynamic information, including, but not limited to, current and forecast weather, 

radar summaries, hazardous condition warnings, infonnation on updated airport 

and airspace capacity constraints, Temporary Flight Restrictions (TFR), and Special Use Airspace 

(SUA) schedules. 

Flight infonnation. . . 

Schedule infonnation. . . 

A-2 

1.5.2 

1 2th bullet 

Traffic information collected by surveillance systems is transmitted to properly equipped 
aircraft. . .to support flight deck decisions. 

A-3 

1.5.3 

2nd bullet 

Enhanced CNS [communication, navigation, and surveillance] systems and automation in aircraft 
complement automation aids on the ground, pennitting more autonomous operations. This 
improved autonomy, combined with greater ability to share information, pennits the workload to 
be distributed between the service provider and user in a balance appropriate for the operations 
being conducted. 

A-4 

1.5.3 

4th bullet 

Seamless communications and coordination, coupled with infonnation accessible through SWIM, 
allow real-time reassignment of airspace between facilities to meet contingencies such as 
equipment outages. 

A- 5 

2.2.1 

1 st paragraph 

Users have access to an increasing amount of NAS information including airport status and 
acceptance rate, . . . 

A-6 

3 

1 st bullet 

Elements of SW[I]M are used to obtain and distribute flight-specific data and aeronautical 
infonnation, including international coordination of flight trajectory. 

A-7 

3.1.1 

3rd paragraph 

There is real time sharing of system demand and the virtual ATM [air traffic management] 
infonnation. . . User flight planning systems account for system constraints such as flow 
restrictions, hazardous weather, SUA and infrastructure outages. 

A-8 

3.1.2 

1 st paragraph 

A NASCR [NAS Common Reference System] and index that incorporates a common 
Geographical Information System (GIS) format is used to store all NAS information including 
terrain, obstacle, weather, and navigation, surveillance and communication coverage information. 
This infonnation is available via SWIM to all service providers and users. 

A-9 

3.1.2 

3rd paragraph 

To generate the flight profile, users access current and predicted weather, traffic density, 
restrictions, and SUA status infonnation . . . 

A-10 

3.2.2 

9th paragraph 

SWIM enables domestic and international users and service providers to access flight profiles and 
associated SUA data. 

A-l 1 

4.1.2 

4th paragraph 

Access to real-time data for surface movement DSSs [decision support systems] makes for an 
increasingly integrated NAS. The surface management information system facilitates coordination 
between decision makers at all levels of the airport operation — service provider, flight crews, 

FOC [Flight Operations Center], ramp, airport operator, and airport emergency centers. The 
system provides access to airport environmental infonnation; arrival, departure, and taxi 
schedules; airborne and surface surveillance information; flight information; ATIS [Automatic 
Terminal Information Service] and other weather information; and TFM [traffic flow 
management] initiatives. This data sharing allows service providers to coordinate local operations 
with airline ramp and airport operators, thus improving overall airport operations. 

A-12 

4.1.3 

1 st paragraph 

.... Using data link, pilots receive ATIS-type messages with Runway Visual Range (RVR), 
braking action and surface condition reports, current precipitation, runway availability, and wake 
turbulence and wind shear advisories. Hazardous weather alerts are automatically and 
simultaneously broadcast to aircraft via data link and service providers via SWIM. 

A-13 

4.2.1 

2nd paragraph 

Airport maps are electronically available to properly equipped users 
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TABLE 43.— IDENTIFICATION OF THE ROLE OF AERONAUTICAL INFORMATION— RTCA NATIONAL 
AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (CONOPS) APPLICABLE TO THE PROPOSED AEROMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

A-14 

4.2.2 

3rd paragraph 

The proliferation of CDTI [cockpit display of traffic information] avionics and supporting ground 
infrastructure takes place in this time frame. The ground system that receives aircraft position 
reports also broadcasts radar-derived traffic information and a complete set of graphical and text 
products . . . Safety is enhanced by situation displays that depict airborne and surface traffic as 
well aerodrome infonnation. 

A-15 

4.3.1 

1 st paragraph 

SWIM and ACARS [Aircraft Communications Addressing and Reporting System] enhance the 
service provider’s ability to provide data products such as NOTAMs [Notices to Airmen] and 
meteorological information for the airport vicinity. Although weather infonnation and advisories 
continue to be available via traditional means, there is increased use of automation to collect and 
package the infonnation and increased use of data link to disseminate routine and hazardous 
weather and traffic information. 
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TABLE 44.— IDENTIFICATION OF THE ROLE OF RESOURCE MANAGEMENT INFORMATION— RTCA NATIONAL 
AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (CONOPS) APPLICABLE TO THE PROPOSED AEROMACS 


ID 

NAS ConOps 
section 

Relevant text (Ref. 14) 

RM-1 

1.5.2 

16th bullet 

By taking advantage of advanced information and communications capabilities, airspace 
design and underlying sector configurations are no longer constrained by the current 
geographic boundaries, particularly in high altitude. Tools and procedures are in place for 
frequent evaluation (up to several times a day) of the airspace structure and anticipated traffic 
flows, with adjustments made accordingly. This increased flexibility permits changes to the 
configuration of air traffic facilities. 

RM-2 

1.5.3 

2nd bullet 

Enhanced CNS [communications, navigation, and surveillance] systems and automation in 
aircraft complement automation aids on the ground permitting more autonomous operations. 
This improved autonomy combined with greater ability to share information permits the 
workload to be distributed between service provider and user in a balance appropriate for the 
operations being conducted. 

RM-3 

1.5.3 

4th bullet 

Seamless communications and coordination, coupled with information accessible through 
SWIM [System Wide Information Management], allow real-time reassignment of airspace 
between facilities to meet contingencies such as equipment outages. 

RM-4 

1.5.3 

7th bullet 

There are continued improvements in the collection and processing of NAS infrastructure 
data. These data are used to prioritize and schedule NAS infrastructure activities 

RM-5 

1.5.3 

8th bullet 

NAS infrastructure assets (e.g., radars, communications, etc.) are assigned/reassigned 
dynamically to mitigate infrastructure problems as well as in response to changes in 
sectorization and airspace assignment. All NAS resources are registered in the NAS Common 
Reference System (NASCR), and monitored and managed through SWIM. 

RM-6 

2.5.3 

. . . NAS infrastructure assets are assigned/reassigned dynamically to mitigate infrastructure 
problems as well as to respond to changes to in sectorization and airspace assignment. SWIM 
provides access to all NAS management and resource infonnation. The redundancy in the 
NAS is applied expeditiously to maintain flow and reduce operational impact 

RM-7 

3.1.1 

3rd paragraph 

There is real-time sharing of system demand and the virtual ATM information, enabling 
service providers to collaboratively interact with the user and to mutually develop solutions to 
problems. . . . User flight planning systems account for system constraints such as flow 
restrictions, hazardous weather, SUA and infrastructure outages. 

RM-8 

5.3.2 

7th paragraph 

Data from SWIM allows service providers to monitor traffic demand, NAS infrastructure 
status, and other conditions in order to allocate resources, including changes in staffing. 
Service providers also update the NAS about the available capacity of airport and surrounding 
airspace resources and the current status of SUA. This facilitates more effective collaboration 
with FOCs [Flight Operations Center] and improved fonnulation of TFM [traffic flow 
management] agreements. 
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Appendix C. — Hierarchical Diagrams of Functional Requirements 

This appendix contains the functional analysis of the AeroMACS C-band communication system 
presented as a series of hierarchical diagrams (Figure 46 to Figure 61). The “C” preceding all of the 
numerical functional levels represents “C-band.” 

The analysis and diagrams were adapted from the National Airspace System Communications System 
Safety Hazard Analysis and Security Threat Analysis document (Ref. 45). 

Solid blocks in the diagrams represent system functions that are part of the C-band system scope 
assumptions, and background blocks show NAS functions that are not currently part of the C-band 
functionality. 



Figure 46. — High-level view of C-band communications system (adapted from Ref. 45). 



Figure 47. — Decomposition of use of C-band communications system to transmit/receive messages 

(adapted from Ref. 45). 
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Figure 48. — Decomposition of transceive fixed-to-mobile message (adapted from Ref. 45). 



Figure 49. — Decomposition of transceive mobile-to-fixed message (adapted from Ref. 45). 
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Fixed to Fixed 
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C.l.1.4.1 
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Fixed to 
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Transceive 
Fixed to 
Fixed 
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Figure 50. — Decomposition of transceive fixed-to-fixed 
message (adapted from Ref. 45). 


HL 

C.l. 1.4. 1.1.1 
Transceive 
Fixed to Fixed 
Voice Message 



Transceive 
Fixed to Fixed 
Data Message 



Figure 51 . — Generic decomposition of transceive data message (adapted from Ref. 45). 


NASA/CR— 201 1-216997/VOL1 


133 














Figure 52. — Generic decomposition of initiate data message (adapted from Ref. 45). 



Figure 53. — Generic decomposition of process data message for sending (adapted from Ref. 45). 



Figure 54. — Generic decomposition of send data message (adapted from Ref. 45). 



Figure 55. — Generic decomposition of process received data message (adapted from Ref. 45). 
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Also terminate 

Figure 56. — Generic decomposition of deliver data message (adapted from Ref. 45). 



Figure 57. — Generic decomposition of provide failure processing (adapted from Ref. 45). 


Failure-detection subfunctions 

• Authentication failures 

• Function unavailability 

• Message unintelligible or garbled 

• Message inaudible 

• Message or message components missing or faulty 

• Invalid or incorrect message components 

• Checksum failures 

• Invalid recipient 



Figure 58. — Decomposition of operate C-band communications system 
(adapted from Ref. 45). 
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C. 1.2.1 
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System 



Determine Indicate Verify 

Status Status Performance 


Figure 59. — Decomposition of monitor C-band 
communications system (adapted from Ref. 45). 


C. 1.2.2 

Maintain L-Band 
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C. 1.2.2. 1.1 
Provide Logistics 
Support 


Perform 

Preventive 

Maintenance 


C. 1.2. 2. 1.2 


Recognize Event 



c.: 

Determine 

Indication 


Determine 

Correction 



Archive 

Information 


Perform 

Corrective 

Maintenance 


Provide Logistics 
Support 



C. 1.2.2 .2.3 
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Indication 



Archive 

Information 


Figure 60. — Decomposition of maintain C-band communications system (adapted from Ref. 45). 
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Figure 61. — Decomposition of configure C-band communications system (adapted from Ref. 45). 
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Appendix D. — Examples of Airport Categories Based on 
Propagation Characteristics 

The following figures present examples of airports categorized based on propagation environment. 
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Figure 62. — Baltimore/Washington International (BWI) Airport. Parallel runways and terminals in 
between; snowflake-like aprons. 
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09351 

AIRPORT DIAGRAM 


ATLANTA/ HARTSFIELD - JACKSON ATLANTA INTL (ATL) 
AL-26 (FAA) ATLANTA, GEORGIA 



Figure 63. — Hartsfield-Jackson Atlanta International Airport (ATL). Parallel runways and terminals 
in-between; grid aprons. 
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Appendix E. — RTCA SC-223 USAS Workbook Summary 

Appendix E summarizes the results of the ongoing work of the RTCA SC-223 USAS WG. The set of 
tables below presents the potential AeroMACS applications identified as “services and applications that 
deserve attention sooner in the data collection process” (Ref. 60). The information is extracted from the 
consolidated workbook that was updated based on the USAS ad-hoc WG meeting discussions on 
October 15, 2010, at the RTCA (Ref. 60) 21 and is presented per functional domain. 


TABLE 45.— POTENTIAL AEROMACS APPLICATIONS: ATM-ATC FUNCTIONAL DOMAIN 


Name 

Owner 

Existing/ 

Mobile/ 

Category 

Performance 

Security 

Transport 

End 

Description/ 



future 

fixed 


requirements 

requirements 

contents 

Points 

Function 


Current ACARS 


Pre 

FAA - 

Existing 

Mobile 

ATS 

Data Rate: L 

Private 

ACARS 

Airport 

Provides 

Departure 

Airline 




Latency 

Network 

Character 

ATC 

Departure 

Clearance 





(RT): H 


-oriented 

Tower & 

Clearance 






Availability: 


datagram 

Service 

information 






VL 



Provider 



SC-214 CPDLC Services 


DTAXI 

Graphical 

Message 

Service 

FAA - 
ANSP 

Future 

Mobile 

ATC 

Data Rate: M 
Latency 
(RT): L 
Availability: 
H 

Authentication 

ATN 

message 

CPDLC 

exchange 

AC- 

TFDM 

Transmit a 
representation 
of the taxi 
route to the 
aircraft for 
display 

4DTRAD 

for 

surface 

movement 

AC & 
ANSP 

Far 

Future 

Mobile 

ATC 

Data Rate: M 
Latency 
(RT): M 
Availability: 
H 

Authentication 




Security 

messaging 

(FAA 

requested) 

FAA 

Future 

Mobile 

ATC 

Data Rate: M 
Latency 
(RT): M 
Availability: 
H 

Authentication 

ATN 

message 

exchange 




COCR Services (not in SC-214 and surface related) 


Metro 
logical 
Info D- 
SIGMET 

FAA 

Future 

Mobile 

ATC 


Authentication 

ATN 

message 

exchange 



Surface 

Informati 

on 

Guidance 

D-SIG 

FAA 

Future 

Mobile 

ATC 


Authentication 

ATN 

message 

exchange 



Wake 

Broadcast 

(WAKE) 

FAA 

Future 

Mobile 

ATC 


Authentication 

ATN 

message 

exchange 



Pilot 

preference 
s (PPD) 

FAA 

Future 

Mobile 

ATC 


Authentication 

ATN 

message 

exchange 



Urgent 

Contact 

(URCO) 

FAA 

Future 

Mobile 

ATC 


Authentication 

ATN 

message 

exchange 




^The version presented here is a work in progress document with the estimated completion time December 31, 2010. 
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TABLE 46.— POTENTIAL AEROMACS APPLICATIONS— AIS & MET FUNCTIONAL DOMAIN 


Application Information/Data 

SWAP Re-routing negotiations 

Data Link Aeronautical Update Service (D-AUS) 

Station NOTAMs 

-Textual aerodrome NOTAMs. 
-Includes a plain text option. 

“Live 10-9” NOTAMs. (Aerodrome NOTAMs overlaid on AMDBs.) 

10-7 Airport Notes Updates 

En route SAA NOTAMs 

Nav aid and procedure NOTAMs. 

Runway configuration infonnation 

MET Data Link Weather Planning Decision Service (D-WPDS) (Per SC-206) 

MET Data Link Weather Near-Term Decision Service (D-WNDS) (Per SC-206) 

MET Data Link Weather Immediate Decision Service (D-WIDS) (Per SC-206) 

Convection products 
-Convective SIGMET 
-Ground Radar 
-Forecast 

Lightning 

Turbulence 

-PIREP (Voice and Auto) 

-GTG (Graphical Turbulence Guidance) 
-SIGMET/AIRMET 

Icing 

-PIREP 

-SIGMET/AIRMET 
-Current Icing Product (CIP) 
-Forecast Icing Potential (FIP) 

Volcanic ash 
-SIGMET 
-Advisory 

Cyclone 

-Tropical depression 
-Tropical storm 
-Hurricane/Typhoon 

Atmosphere synopses 
-Surface Analysis 
-Surface Prog 
-Upper Air Analysis 
-Upper Air Prog 

Wind 

-Aloft 

-Airport Surface 
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TABLE 46.— POTENTIAL AEROMACS APPLICATIONS— AIS & MET FUNCTIONAL DOMAIN 


Application Information/Data 

Temperature 


-Aloft 


-Surface 


Pressure 


-Aloft 


-Surface 



Windshear 
-Microburst 
-Windshear Alert 


-LLWS 
-PIREP 
Precipitation 
-Ground Radar 
-METARs/SPECIs & TAFs 
-Area Forecast 
-Surface Analysis Forecast 
Cloud 

-METAR/TAF 

-Satellite 

-AIRMET (IFR/Mountain Obscuration) 

-Area Forecast 
-PIREP 
Visibility 
-RVR 

-METAR/TAF 
-Area Forecast 
Ozone 14 CFR 25.183. 

Space weather 
Operational Category 

-VFR, MVFR, IFR, Low IFR 
D-OTIS (DL Operational Terminal Information Service) 
-D-NOTAM 

D-RVR (DL Runway Visual Range Service) 

D-HZWX (DL - Hazardous Weather) 

-D-SIGMET 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

VoIP Transmissions (Examples below) 




Fueling Crew 


1 Fuel Handler 

2 Fuel Dispatch 
Office 

Coordination of fueling 
operations 

Wheel Chairs 


1 Wheel Chair Pusher 

2 WC Coordination 
Office 

Coordination of wheel chair 
service 

Catering Crew 



Coordination of catering, 
food, water operations 

De Ice Crew 


1 Dc Ice Crew 

2 Dispatch Office 

3 Aircraft— VHF 

Coordination of Dc ice ops 

Maintenance Crew 


1 Maintenance Tech 

2 Maint Supvr 

3 Maint Ops Coord 

Coordination of unscheduled 
maintenance 

Ground Crew 


1 Taxi Director 
Wing Walkers 

2 Maint Crew 

3 Jetway Driver 

4 Catering Crew 

5 Tow Tug Driver 

6 Fueling Crew 

7 Ground Ops Power 

8 Air-conditioning 

9 Bag Handlers 

10 Concourse Supv 

1 1 Red Coat Ops 

12 Check in Ops 

13 Customs 

14 Immigration 

1 5 Gate assignment 

16 Cargo Handlers 

17 Sanitation Crew 

18 Aircraft Cleaning 

Coordination of aircraft 
handling 

Cargo Operations 



Coordination of Cargo 
Operations 

Bags 


1 Bag handlers 

2 Gate handlers 

3 Check in 

4 Bag Recovery 

Coordination of passenger 
bags 

Gate Info 


1 Ground Crew 

2 Station Ops 

Aircraft gate assignments 

Weather Ops 


1 Station Ops 

2 Ground Crews 

3 Supervisors 

4 Flight Crews 

Coordinate change 
management due to weather 
issues 

Gate Returns 


1 Ground Crew 

2 Supervisors 

3 Specialty Crews 

Coordinate gate assignment 
and ground support 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

Security 



Coordinates ground security 

Ground Clearance 


1 Gate Crews 

2 Pilots 

3 Wt & Balance 

4 Central Dispatch 

5 Station Ops 

Coordinates flight release 

Fire Department 


1 Ground Crew 

2 Station Ops 

3 Gate Ops 

4 Supervisors 

Emergency comm with fire 
dept 

AIS Datalink Baseline Synchronization 
Service (D-BSS) (i.e., Complete 
Synchronization & Update 
Synchronization Per DO-308) Products 
include: 




-Aerodrome Charts (pre-composed) 




-Aerodrome Charts (data-driven) 

Existing (Data 
loader, wireline, 
and/or wireless) 

Owner/Operator or 
Service Provider to 
AC 

BSS 28 days or less 

-Standard Instrument Departures 
(SIDs) (pre-composed) 




-Standard Instrument Departures 
(SIDs) (data-driven) 




-Engine-Out Procedures (pre- 
composed) 




-Engine-Out Procedures (data-driven) 




-IFR En Route Charts (pre-composed) 




-IFR En Route Charts (data-driven) 




-VFR Aeronautical Charts (pre- 
composed) 




-VFR Aeronautical Charts (data- 
driven) 




-Standard Terminal Arrival Routes 
(STARs) (pre-composed) 




-Standard Terminal Arrival Routes 
(STARs) (data-driven) 




-Instrument Procedures (pre- 
composed) 




-Instrument Procedures (data-driven) 




-Charted Visual Approach Procedures 
(pre-composed) 




-Charted Visual Approach Procedures 
(data-driven) 




-Noise Abatement Procedures (pre- 
composed) 




-Noise Abatement Procedures (data- 
driven) 




-Terrain 




-Obstacles 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

-FMS and GPS navigation data bases 
(ARINC 424 DB) 




-Other Onboard Loadable software 

Existing 

(Dataloader, CD) 



System monitoring (routine) 




-Engine condition monitoring 

ACARS 



-Airframe, avionics and systems 
condition monitoring 

ACARS 



Electronic Logbooks 

Intranet or Gatelink 



FOQA Data 

Data loader or 
Gatelink 



Update of EFB Databases, Company 
manuals & SOPs highlighted in yellow for 
details 




-Flight Operations Manuals (FOM) 

Intranet or Gatelink 



-Company Standard Operating 
Procedures (SOP) 

Intranet or Gatelink 



-Airport diversion policy guidance, 
including a list of Special Designated 
Airports and/or approved airports 
with emergency medical service 
(EMS) support facilities 

Intranet or Gatelink 



-Operations Specifications (OpSpecs) 

Intranet or Gatelink 



-Cockpit observer briefing cards 

Intranet or Gatelink 



-Airplane Flight Manuals (AFM) and 
Airplane Flight Manual Supplements 
(AFMS) 

Intranet or Gatelink 



-For smaller aircraft, Pilot Operating 
Handbooks (POH), including POH 
section IX supplements 

Intranet or Gatelink 



-Aircraft performance data (fixed, 
non-interactive material for planning 
purposes) 

Intranet or Gatelink 



-Airport performance restrictions 
manual (such as a reference for 
takeoff and landing performance 
calculations 

Intranet or Gatelink 



-Other aircraft performance data, 
including specialized performance 
data for use in conjunction with 
advanced wake vortex modeling 
techniques, land-and-ho ld-short 
operations (LAHSO) predictions, etc. 
(fixed, non- interactive material for 
planning purposes) 

Intranet or Gatelink 



-Maintenance manuals (Instructions 
for continued airworthiness) 

Intranet or Gatelink 



-Aircraft maintenance reporting 
manuals 

Intranet or Gatelink 



-Aircraft flight log and servicing 
records 

Intranet or Gatelink 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

-Autopilot approach and autoland 
records 

Intranet or Gatelink 



-Flight Management System/Flight 
Management and Guidance System 
problem report fonns 

Intranet or Gatelink 



-Aircraft parts manuals (Configuration 
control) 

Intranet or Gatelink 



-Service bulletins/published 
Airworthiness Directives, etc. 

Intranet or Gatelink 



-Air Transport Association (ATA) 100 
format maintenance discrepancy 
write-up codes 

Intranet or Gatelink 



-Required VHF Omni directional 
Range (VOR) check records 

Intranet or Gatelink 



-Minimum Equipment Lists (MEL) 

Intranet or Gatelink 



-Configuration Deviation Lists (CDL) 

Intranet or Gatelink 



-Federal, state, and airport-specific 
rules and regulations 

Intranet or Gatelink 



-Airport/Facility Directory (A/FD) 
data (e.g., fuel availability, LAHSO 
distances for specific runway 
combinations, etc.) 

Intranet or Gatelink 



-Noise abatement procedures for 
arriving and departing aircraft 

Intranet or Gatelink 



-Published (graphical) pilot Notices to 
Airmen (NOTAM) 

Intranet or Gatelink 



-International Operations Manuals, 
including regional supplementary 
information and International Civil 
Aviation Organization (ICAO) 
differences 

Intranet or Gatelink 



-Aeronautical Infonnation 
Publications (AIP) 

Intranet or Gatelink 



-Aeronautical Infonnation Manual 
(AIM) 

Intranet or Gatelink 



-Oceanic navigation progress logs 

Intranet or Gatelink 



-Pilot flight and duty-time logs 

Intranet or Gatelink 



-Flight crew required rest logs 

Intranet or Gatelink 



-Flight crew qualification logs (such as 
aircraft qualifications, Class II flight 
crew qualifications, Category (CAT) 
III qualifications, high minimums 
logs, night currency logs, pilot-in- 
command (PIC) qualifications for 
special areas, routes and airports for 
part 121 certificate holders, and 
special airports qualifications) 

Intranet or Gatelink 



-Captain’s report (i.e., captain’s 
incident reporting fonn) 

Intranet or Gatelink 



-Flight crew survey forms (various) 

Intranet or Gatelink 



-Flight Attendant Manuals 

Intranet or Gatelink 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

-EMS reference library (for use during 
medical emergencies) 

Intranet or Gatelink 



-Trip scheduling and bid lists 

Intranet or Gatelink 



-Aircraft’s captain’s logs 

Intranet or Gatelink 



-Aircraft’s CAT II/CAT III landing 
records 

Intranet or Gatelink 



-Antiterrorism profile data 

Intranet or Gatelink 



-Hazardous Materials 
(HAZMAT)/oxidizer look-up tables 

Intranet or Gatelink 



-Emergency Response Guidance for 
Aircraft Incidents Involving 
Dangerous Goods (ICAO Doc 9481- 
AN/928) 

Intranet or Gatelink 



-Customs declaration and United 
States Department of Agriculture 
(USDA) agriculture inspection / 
clearance form 

Intranet or Gatelink 



-Special reporting forms, such as near 
mid-air collision (NMAC) reports, 
National Aeronautics and Space 
Administration’s (NASA) Aviation 
Safety Reporting System (ASRS), 
bird and wildlife encounters, owner- 
initiated Service Difficulty Reports 
(SDR), etc. 

Intranet or Gatelink 



-Incidents of interference to aircraft 
electronic equipment from devices 
carried aboard aircraft 

Intranet or Gatelink 



-Current fuel prices at various airports 

Intranet or Gatelink 



-Realistic training module s, including 
“PC at home” training applications, 
“off-duty” training materials review, 
and pre- flight “mission” rehearsals 

Intranet or Gatelink 



-Check airman and flight instructor 
records 

Intranet or Gatelink 



-Aircraft operating and information 
manuals (performance information, 
weight and balance, systems, 
limitations, etc.) 

Intranet or Gatelink 



-Flight operations manuals including 
emergency procedures 

Intranet or Gatelink 



-Airline policies and procedures 
manuals 

Intranet or Gatelink 



-Aircraft Maintenance Manuals 

Intranet or Gatelink 



-Title 14 of the Code of Federal 
Regulations (14 CFR) 

Intranet or Gatelink 



-Look-up and completion of various 
reporting forms, e.g., company- 
specific forms, NASA’s ASRS 
reports, NMAC reports, wildlife 
strike and hazard reports, etc. 

Intranet or Gatelink 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

-Maintenance personnel sign-off of 
discrepancy form. (Maintenance 
discrepancy logs need to be 
downloaded into a permanent record 
at least weekly.) 

Intranet or Gatelink 



-Flight crew qualifications 
recordkeeping, including aircraft 
qualifications, CAT I I/I 1 1 , high 
minimums, landing currency, flight 
and duty time, etc. 

Intranet or Gatelink 



-PIC currency requirements 

Intranet or Gatelink 



-The Flight Attendant Manual 

Intranet or Gatelink 



-Passenger information requests — 
some are directed to the gate or to the 
agent meeting the flight (e.g., special 
meal requests, wheel chair 
requirements, unaccompanied minors, 
gate information for connecting 
flights, flights being held for 
connecting passengers, etc.) 

Intranet or Gatelink 



-Cabin maintenance write-ups. 
(Maintenance discrepancy logs need 
to be downloaded into a pennanent 
record at least weekly.) 

Intranet or Gatelink 



-Approved electronic signature using 
public/private key technology (PKI) 

Intranet or Gatelink 



-Takeoff, en route, approach and 
landing, missed approach, go-around, 
etc., performance calculations. Data 
derived from algorithmic data or 
performance calculations based on 
software algorithms. 

Intranet or Gatelink 



-Power settings for reduced thrust 
settings 

Intranet or Gatelink 



-Runway limiting performance 
calculations 

Intranet or Gatelink 



-Cost index modeling 

Intranet or Gatelink 



-Master flight plan/updating 

Intranet or Gatelink 



-Interactive Plotting for Class II 
navigation 

Intranet or Gatelink 



-Mission rehearsals 

Intranet or Gatelink 



-Weight and balance calculations 

Intranet or Gatelink 



-Maintenance discrepancy sign-off 
logs. (Maintenance discrepancy logs 
need to be downloaded into a 
pennanent record at least weekly.) 

Intranet or Gatelink 



-Cabin maintenance discrepancy 
reporting forms/location codes. 
(Maintenance discrepancy logs need 
to be downloaded into a pennanent 
record at least weekly.) 

Intranet or Gatelink 
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TABLE 47.— POTENTIAL AEROMACS APPLICATIONS— AIRLINES/CARGO OPERATIONS (AIRLINE-CARGO 
OPS) AND D-BSS (BASELINE SYNC SERVICE) FUNCTIONAL DOMAIN 


Name 

Existing/Future 

End Points 

Description/Function 

-Non-interactive electronic approach 
charts in a pre-composed fonnat from 
accepted sources 

Intranet or Gatelink 



-Panning, zooming, scrolling, and 
rotation for approach charts. 

Intranet or Gatelink 



-Pre-composed or dynamic interactive 
electronic aeronautical charts (e.g., en 
route, area, approach, and airport 
surface maps) including, but not 
limited to, centering and page turning 
but without display of aircraft/own- 
ship position. 

Intranet or Gatelink 



-Electronic checklists, including 
normal, abnormal, and emergency. See 
the current version of Advisory 
Circular (AC) 120-64, Operational Use 
& Modification of Electronic 
Checklists, for additional guidance. 
EFB electronic checklists cannot be 
interactive with other aircraft systems. 

Intranet or Gatelink 



-Applications that make use of the 
Internet and/or other aircraft 
operational communications (AOC) 
or company maintenance-specific 
data links to collect, process, and then 
disseminate data for uses such as 
spare parts and budget management, 
spares/inventory control, unscheduled 
maintenance scheduling, etc. 
(Maintenance discrepancy logs need 
to be downloaded into a pennanent 
record at least weekly.) 

Intranet or Gatelink 



-Weather and aeronautical data 

Intranet or Gatelink 



-Cabin-mounted video and aircraft 
exterior surveillance camera displays 

Intranet or Gatelink 



Integrated Pilot Information Bulletin (PIB) 
[AIS & MET data] Also includes AIP 
data, as needed 




MEL / MRD / CDL 

Paper/ ACARS 



Dispatch Release 

Paper/ ACARS 



Initial & final weight and balance data 

Paper/ ACARS 



ATC ADS-B back-up surveillance data (to 
mitigate against reflected ADS-B signals) 




Refueling Data 

Paper/ ACARS 



FMS wind field data 




Hazardous cargo manifest documentation 




Before or after before engine checklist: 
AIS & MET Data Link Services 




Electronic transmission of misc 
documentation to crew, e.g., duplicate 
pilot or medical certificates, missing paper 
chart replacement 
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TABLE 48.— POTENTIAL AEROMACS APPLICATIONS— AIRPORT OPERATION FUNCTIONAL DOMAIN 


Name 

Owner 

Existing/ 

Future 

Mobile/ 

Fixed 

Category 

Performance 

Requirements 

Security 

Requirements 

Transport 

Contents 

End Points 

FAR 139 Safety Self Inspection 

Navigational 
Aids System 
Maint. 

Airport 

Authority 

Existing 

Existing is 
fixed, 
would like 
to migrate 
to Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:M 

Authentication 

Text & 

Light 

Graphics 

OPS 
Server - 
Computer 

Signage 

Airport 

Authority 

Existing 

Existing is 
fixed, 
would like 
to migrate 
to Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:M 

Authentication 

Text & 

Light 

Graphics 

OPS 
Server - 
Computer 

Pavement 

Management 

System 

Airport 

Authority 

Existing 

Existing is 
fixed, 
would like 
to migrate 
to Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:M 

Authentication 

Text & 

Light 

Graphics 

OPS 
Server - 
Computer 

FOD 

management 

Airport 

Authority 

Existing 

Existing is 
fixed, 
would like 
to migrate 
to Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:M 

Authentication 

Text & 

Light 

Graphics 

OPS 
Server - 
Computer 

Snow 
Removal 
Monitoring 
and Ice 
Control 

Airport 

Authority 

Existing 

Existing is 
fixed, 
would like 
to migrate 
to Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:M 

Authentication 

Text and 

Light 

Graphics 

Ops - 
Vehicle 

Wildlife 

Management 

System 

Airport 

Authority 

Existing 

Existing is 
fixed, 
would like 
to migrate 
to Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:M 

Authentication 

Text and 

Light 

Graphics 

Server - 
Computer/ 
Ip ad 

AVL - Geo 
Fencing and 
Movement 
Area 

Management 

Airport 

Authority 

Future 

Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: M 
Latency (RT):L 
Availability:M 

Authentication 

Text & 
graphics 

Server - 
Computer/ 
Ip ad 

Public Safety Handheld & vehicle-mounted mobile data tenninals 

Fire 

Airport 

Authority 

Future 

Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:H 

Authentication 

Text & 

light 

graphics 

Server - 
Hand held 
devices 
and 

vehicle 

mounted 

Emergency 

Management 

(EMD) 

Airport 

Authority 

Future 

Mobile 

Airport 

Operations: 

Airfield 

Operations 

Data Rate: L 
Latency (RT):L 
Availability:H 

Authentication 

Text & 

light 

graphics 

Server - 

Hand held 

devices 

and 

vehicle 

mounted 


NASA/CR — 201 1-216997/VOL1 


150 





TABLE 49.— POTENTIAL AEROMACS APPLICATIONS— AIRPORT INFRUSTRUCTURE FUNCTIONAL DOMAIN 


Name 

Owner 

Existing/ 

Future 

Mobile/ 

Fixed 

Performance 

Requirements 

Security 

Requirements 

Transport 

Contents 

Description/ 

Function 

Comments 

Airport Surface 
Detection Equipment 
X (ASDE-X) 

FAA 

E 

F 

Routine 

BDl, ED3 

SM Data 

Surface 

Movement Data 

(ATCT to 

ASDE, 

HDQ, 

VOR, 

ASR, 

IMDS, 

OPIP) 

Airport Surface 
Detection Equipment 
3 (ASDE-3) 

FAA 

E 

F 

Routine 


SM Data 

Surface 

Movement Data 


Remote Transmitter- 
Receiver (RT/R) 

FAA 

E 

F 

Critical 


ATC 

Voice 

Provides pilot-to- 
controller voice 
communications 
in the tenninal 
area. 
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